Iroha supports "live" queries. They allow clients to make a query with first request and then continue making requests and retrieve batches of data from the same query. They do it by sending a ForwardCursor from Iroha back to Iroha.
There is a timeout after which, if clients do not continue interact with not yet exhausted query, that query becomes no longer available. This timeout is configured for each Iroha instance separately.
Problem
The expiration timeout is not visible for clients. So they don't have any way to know if a query is expired except for making another request to Iroha and receiving an error.
Possible solutions
Extend ForwardCursor structure: add a field which will tell the expiration time of this cursor.
Extend GET /config endpoint data with live query expiration limit
Document clearly how expiration works - from the beginning of the query, or from the latest client request?
Benefits
Makes Query API less vague in general
Gives a clearer way for clients to handle query expiration
Description
Iroha supports "live" queries. They allow clients to make a query with first request and then continue making requests and retrieve batches of data from the same query. They do it by sending a
ForwardCursorfrom Iroha back to Iroha.There is a timeout after which, if clients do not continue interact with not yet exhausted query, that query becomes no longer available. This timeout is configured for each Iroha instance separately.
Problem
The expiration timeout is not visible for clients. So they don't have any way to know if a query is expired except for making another request to Iroha and receiving an error.
Possible solutions
ForwardCursorstructure: add a field which will tell the expiration time of this cursor.GET /configendpoint data with live query expiration limitBenefits