Stream Subscriber Plugin Rework Interaction Between Plugin and Sessions #1691
Description
Story Form
As a Block Node Engineer
I want to have a well separated concerns between the Subscriber Plugin and individual sessions
So that the functionality is easily maintainable
Technical Notes
DEPENDS ON: #1556
- it has been noted that the plugin could do request validation before even creating a session
- it has been noted that the plugin could be responsible for handling responses that a session could be returning in some situations
- this could include a session has completed exceptionally or the session encounters a state where it cannot continue (example could be that a block accessor for a historical block is issued, but the block is inaccessible)
- we should think about and design properly these interactions, splitting correctly responsibilities
- the session would probably become leaner
- a possible solution could be to introduce a block session manager which could be called reactively when a session has something to report