Closed josepot closed 1 year ago
In case where the JSON-RPC client isn't reading from its socket quickly enough, the server can choose to not emit broadcasted
events.
If then the server emits a dropped
event, the client might not be aware that the transaction has been broadcasted.
An alternative way to solve this problem would be making it mandatory for the server to generate a broadcasted
event before a dropped
event when relevant. But having a broadcasted
field in the dropped
event itself makes it more clear that the JSON-RPC client will get the information.
In case where the JSON-RPC client isn't reading from its socket quickly enough, the server can choose to not emit
broadcasted
events. If then the server emits adropped
event, the client might not be aware that the transaction has been broadcasted.An alternative way to solve this problem would be making it mandatory for the server to generate a
broadcasted
event before adropped
event when relevant. But having abroadcasted
field in thedropped
event itself makes it more clear that the JSON-RPC client will get the information.
Awesome! That makes a lot of sense. I personally don't think we need to make the broadcasted
event a must. Still, it could help to be a bit more explicit in the docs, and spell out that you might get a dropped
event marked as broadcasted: true
, even if you didn't see a broadcasted
event before.
I will try to find the time to open a small PR with that later today. Thanks @tomaka !
Could the
broadcasted
field in thedropped
event, generated by thetransaction_unstable_submitAndWatch
call, be considered redundant? Would it be possible to determine its value solely based on the occurrence of thebroadcasted
event?In other words, are there any situations where the value of the
broadcasted
field in thedropped
event couldn't be inferred from the emission of abroadcasted
event? I am not doubting the usefulness of the field, I'm just trying to understand whether there is a situation in which it can't be derived.cc @tomaka