What problem does your feature solve?
We've heard/seen a lot of comments that the getEvents API (or just getting events from RPC in general) is either confusing, deficient, or unintuitive in various ways. Some recent examples:
Additional ones we recently identified but that are not captured in issues:
- Inability to filter
getEvents by transaction hash or transaction id (alternatively, events as a top-level field on getTransactions/getTransaction)
- Possibility of RPC returning an empty page due to sparse events, but the client should still be able to page forward and may get more events
endLedger in the paging queries is completely unused/ignored, leading to the inability for a client to get all the things in a single ledgercursor values produced by RPC can send you beyond RPC's retention window (into the future)- No ability to stream; websockets, sse, or otherwise
- json-rpc << rest
Add onto this, that events are likely to get significantly more focus now that CAP-67 and unified events are on the horizon for protocol 23.
What would you like to see?
We think it's worth it to do a new product-pass on this with fresh eyes, and explore what a better overall UX could be. How exactly we would manage this in terms of rollout or versioning/deprecating the API itself is not in scope here.
What problem does your feature solve?
We've heard/seen a lot of comments that the
getEventsAPI (or just getting events from RPC in general) is either confusing, deficient, or unintuitive in various ways. Some recent examples:eventsas a top-level field in getTransaction response #389cursoropaque to the client #418orderparameter togetEventsfor descending order support #575Additional ones we recently identified but that are not captured in issues:
getEventsby transaction hash or transaction id (alternatively,eventsas a top-level field ongetTransactions/getTransaction)endLedgerin the paging queries is completely unused/ignored, leading to the inability for a client to get all the things in a single ledgercursorvalues produced by RPC can send you beyond RPC's retention window (into the future)Add onto this, that events are likely to get significantly more focus now that CAP-67 and unified events are on the horizon for protocol 23.
What would you like to see?
We think it's worth it to do a new product-pass on this with fresh eyes, and explore what a better overall UX could be. How exactly we would manage this in terms of rollout or versioning/deprecating the API itself is not in scope here.