You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to consume the output of /block I hit the following error
<interactive>: parseTimeOrError: no parse of "2024-05-02T01:47:36.734781Z"
CallStack (from HasCallStack):
error, called at libraries/time/lib/Data/Time/Format/Parse.hs:124:15 in time-1.12.2:Data.Time.Format.Parse
it "Can query /block and parse the result"$const$do
-- @NOTE: this defaults to latest block
result ::EitherRPC.JsonRpcExceptionRPC.ResultBlock<- try $ runRPC (RPC.block def)
result `shouldSatisfy` isRight
but if we add a print result we correctly get
Failures:
(...)
libraries/time/lib/Data/Time/Format/Parse.hs:124:15:
2) KVStore.Test.KV, Tendermint KV Store - via hs-tendermint-client, Can query /block and parse the result
uncaught exception: ErrorCall
parseTimeOrError: no parse of "2024-05-02T19:19:06.123194Z"
CallStack (from HasCallStack):
error, called at libraries/time/lib/Data/Time/Format/Parse.hs:124:15 in time-1.12.2:Data.Time.Format.Parse
it seems like we're not fully forcing the Success value in
The tests definitely should be dealing with the normal form of the value but I'm not sure what the lib should be doing, given this can only be a problem when using unsafe code.
The current behavior preserves laziness but leads to unsafe code having unexpected behavior, which suggests a need for a strict option, even if less performant when the entire value isn't needed. In which case, that could replace the current behavior or exist alongside it.
To avoid duplicating every endpoint, maybe results could be wrapped in a newtype that users then need to choose to "run" lazily or strictly so a conscious choice is made every time?
EDIT: corrected the source of the excessive laziness issue
The text was updated successfully, but these errors were encountered:
When trying to consume the output of /block I hit the following error
this is triggered by
kepler/hs-abci-types/src/Network/ABCI/Types/Messages/FieldTypes.hs
Lines 109 to 110 in 6c1ad7f
the root problem seems to be trying to parse a length of time when the field is actually a timestamp
Confusingly, the test suite suggests this endpoint is actually working properly
kepler/hs-tendermint-client/kv-test/KVStore/Test/KVSpec.hs
Lines 44 to 47 in 6c1ad7f
but if we add a
print result
we correctly getit seems like we're not fully forcing the
Success
value inkepler/hs-tendermint-client/src/Network/Tendermint/Client/Internal/RPCClient.hs
Lines 174 to 178 in 6c1ad7f
so this blows up in client code eventually.
The tests definitely should be dealing with the normal form of the value but I'm not sure what the lib should be doing, given this can only be a problem when using unsafe code.
The current behavior preserves laziness but leads to unsafe code having unexpected behavior, which suggests a need for a strict option, even if less performant when the entire value isn't needed. In which case, that could replace the current behavior or exist alongside it.
To avoid duplicating every endpoint, maybe results could be wrapped in a newtype that users then need to choose to "run" lazily or strictly so a conscious choice is made every time?
EDIT: corrected the source of the excessive laziness issue
The text was updated successfully, but these errors were encountered: