Programmatically comprehensible jetstream errors?

[bittrance]

It seems all errors in the jetstream module are converted into io::Error and type erased before passed to the caller. This makes it hard to write code that differentiate error cases. For example, upserting a kvstore seems to require parsing display strings? Or am I missing something?

What is the maintainers' ambition here? There is an open PR #477 that seems to be a halfway implentation. Can I help?

[bittrance]

For completeness, I should mention that e.g. Context.create_key_value is idempotent, so it effectively works as an upsert operation, but Context.get_key_value seems not to programmatically distinguish between "not found" and e.g. communication errors. Much of this issue could equally be addressed with making the various getters return Option<_>. Perhaps that might be desirable regardless of detailed errors?

[Jarema]

@bittrance we will resume work on #632 shortly, then follow it up with JetStream.

About your second point: that is a possible approach, but errors we return to the users, are anyway not only communication errors.
In some APIs we do return Option<> when something was not found (always in iterators), but we also do not want to force users to check against both Option and Result to get to meaningful data, so there is a need for a balance. Error returning This That Not Found tells user more than just an Option::None which might in some cases need undersanding NATS internals.