Update transactions based on subscriptions events and remove polling

[denishacquin]

I have successfully switched to a subscription model, however, because our websocket connections are scoped to a socketio client id and that client ID is renewed on reload by socketio and because we don't have the polling anymore, we have a slight edge case where the browser won't be notified of a tx being updated if it's pending when the page loads. (but reloading the page after the tx is finalized correctly updates the tx since we still do an initial request to update all pending txs).

This is not a huge deal breaker for now since the user has to reload while some txs are pending for this symptom to appear + one more reload and the tx get updated by the initial query.

This is because we had to scope the socketio connections to clientIds while hosting, otherwise all users would have gotten all events from other users.

Some solutions:

• Ideal: Have a server-side cookie/session system that would follow usual practice and scope events to each browser client (I started trying to do it in Python but I haven't managed to achieve that yet). Would more future proof for hosted env and security. Haven't been able to make it work yet however :(
• Compromise: Remove the scoping by clientId altogether, effectively re-broadcasting all events to all users which doesn't matter when developing locally, but can not work for a hosted env.
• Compromise: Have the clients generate their own session id and have the server generate dedicated rooms based on that; should work but not safe for hosted because clients get to determine which room they join.
• Or do nothing for now as this is still somewhat edge case.

Thoughts welcome @cristiam86 @AgustinRamiroDiaz

[AgustinRamiroDiaz]

@denishacquin sorry but I don't quite understand the problem.

On another topic, I thought the idea was to do broadcasting of all events, an then each client would just subscribe to the events they are interested in (by transaction hash for example)

[denishacquin]

You're right, I'll add tx-scoped subs then. I think we can have the transaction-based events scoped by transaction room/subscription and the other events can remain scoped to the socketio client IDs.

[AgustinRamiroDiaz]

Awesome! Let me know if there's still an edge case I didn't think of One key thing would be to remove the client ID from the Transactions table

[denishacquin]

Removed the column from the model, as well as all occurences and added migration.

To sum it up: transactions are scoped to clients based on client-side explicit subscriptions to specific rooms (=hash), while the other logs are still scoped to socket client IDs.

[github-actions[bot]]

:tada: This issue has been resolved in version 0.20.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: