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
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
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
When trying to consume the output of /block I hit the following error
this is triggered by https://github.com/f-o-a-m/kepler/blob/6c1ad7f37683f509c2f1660e3561062307d3056b/hs-abci-types/src/Network/ABCI/Types/Messages/FieldTypes.hs#L109-L110
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 https://github.com/f-o-a-m/kepler/blob/6c1ad7f37683f509c2f1660e3561062307d3056b/hs-tendermint-client/kv-test/KVStore/Test/KVSpec.hs#L44-L47
but if we add a
print result
we correctly getit seems like we're not fully forcing the
Success
value in https://github.com/f-o-a-m/kepler/blob/6c1ad7f37683f509c2f1660e3561062307d3056b/hs-tendermint-client/src/Network/Tendermint/Client/Internal/RPCClient.hs#L174-L178 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