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
The only certainty we currently have (assuming there are no bugs in this area) is that the fields of a message sent from natskell to NATS will be of the correct 'type' for NATS to consume (type being a loose definition since they are in a string, but if something is a bool or an int for e.g we can be confident NATS will get that type. However there are cases where values of the correct type are still not valid for e.g an empty string in a mandatory string field is allowed by our client currently.
Adding a new set of functions for loosely validating the values of each field could help mitigate this. A class and class constraint could be added to ensure we're using valid types.
The text was updated successfully, but these errors were encountered:
It might be worth validating that the byte count sent is actually correct - which would mean storing the bytecount. Not sure now easy this is with the current record syntax used for the transformable types
It might be worth validating that the byte count sent is actually correct - which would mean storing the bytecount. Not sure now easy this is with the current record syntax used for the transformable types
We don't need to store it, just need to expose a function that takes the given type and returns the byte count, like the other getters
The only certainty we currently have (assuming there are no bugs in this area) is that the fields of a message sent from natskell to NATS will be of the correct 'type' for NATS to consume (type being a loose definition since they are in a string, but if something is a
bool
or anint
for e.g we can be confident NATS will get that type. However there are cases where values of the correct type are still not valid for e.g an emptystring
in a mandatory string field is allowed by our client currently.Adding a new set of functions for loosely validating the values of each field could help mitigate this. A class and class constraint could be added to ensure we're using valid types.
The text was updated successfully, but these errors were encountered: