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
There is a need for some users to inject state into plugin init using more than just yaml. In particular if users are trying to test the router and their plugin relies on an external long lived state then a static are their only option right now.
Statics and tests don't mix well.
Proposal
Add the ability to inject state into plugins and have this participate in the normal lifecycle of the router. This would transmit state from supplied when building Executable to all plugins via PluginInit
Proposed implementation:
StateMachine currently takes a stream of events that supply config, schema, and license.
The proposal is to add two new additional variants to the Event enum:
CustomState
NoMoreCustomState
The state machine will be modified to expect at least one CustomState event before starting. The off the shelf router will have a stream of empty custom state followed by no more custom state. This is in line with the other event types.
We have to decide how to transmit the custom state to plugins. Maybe this can be added as a type parameter on Event and propagated to PluginInit. However the developer will have to see what the impact is. If it would change public APIs or the blast radius is huge then downcasting is an option. PluginInit will be extended to have a new method that returns an the custom state.
Executable will be extended to accept CustomStateSource in the same way as the existing sources. and will be documented for public use.
The text was updated successfully, but these errors were encountered:
Problem
There is a need for some users to inject state into plugin init using more than just yaml. In particular if users are trying to test the router and their plugin relies on an external long lived state then a static are their only option right now.
Statics and tests don't mix well.
Proposal
Add the ability to inject state into plugins and have this participate in the normal lifecycle of the router. This would transmit state from supplied when building
Executable
to all plugins viaPluginInit
Proposed implementation:
StateMachine
currently takes a stream of events that supply config, schema, and license.The proposal is to add two new additional variants to the Event enum:
The state machine will be modified to expect at least one
CustomState
event before starting. The off the shelf router will have a stream of empty custom state followed by no more custom state. This is in line with the other event types.We have to decide how to transmit the custom state to plugins. Maybe this can be added as a type parameter on
Event
and propagated toPluginInit
. However the developer will have to see what the impact is. If it would change public APIs or the blast radius is huge then downcasting is an option.PluginInit
will be extended to have a new method that returns an the custom state.Executable
will be extended to acceptCustomStateSource
in the same way as the existing sources. and will be documented for public use.The text was updated successfully, but these errors were encountered: