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
Currently callers have to poll for /replies that contain the asynchronous responses to kld-sync=false requests.
We now have a WebSocket interface on ethconnect, which can be used (as an alternative to Webhooks) to listen for events emitted from smart contracts.
It would be great to be able to use this same interface to listen for the TransactionSuccess/TranscationFailure events as they arrive in the receipt store, to more immediately trigger downstream processing.
However, that would be quite a big lift in the model.
Another option would be something much lighter weight such as a new REST operation like POST/replies/listen , that took a new payload with topic inside it, and just kept pumping replies down there until the ethconnect process restarted.
This would mean it would be necessary for the app to re-listen every time, which might lead to missed events while the app is disconnected.
The text was updated successfully, but these errors were encountered:
Currently callers have to poll for
/replies
that contain the asynchronous responses tokld-sync=false
requests.We now have a WebSocket interface on ethconnect, which can be used (as an alternative to Webhooks) to listen for events emitted from smart contracts.
It would be great to be able to use this same interface to listen for the
TransactionSuccess
/TranscationFailure
events as they arrive in the receipt store, to more immediately trigger downstream processing.There's a little complexity here, that we would need a way to "subscribe" a WebSocket topic to receive the events.
One option would be a new type of subscription that is connected to the replies, rather than the blockchain:
https://github.com/kaleido-io/ethconnect/blob/3cbf3daa386eee0eaeae56f03a3923f1b89bc923/internal/kldevents/subscription.go#L44-L54
However, that would be quite a big lift in the model.
Another option would be something much lighter weight such as a new REST operation like
POST
/replies/listen
, that took a new payload withtopic
inside it, and just kept pumping replies down there until the ethconnect process restarted.This would mean it would be necessary for the app to re-listen every time, which might lead to missed events while the app is disconnected.
The text was updated successfully, but these errors were encountered: