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
Context
Research on #335 is complete, and the following design has been settled on:
A main relayer application that is (optionally) configurable to dispatch to an external Decider service
The main relayer application will directly implement a subset of the decision logic. Exactly what is implemented in the main relayer application versus the Decider service is an open question.
A default sidecar (or template) that implements the Decider service as a local process. This can be extended to implement arbitrary logic. It is on open question if we will ship this sidecar.
Decider deployment and implementation details are fully abstracted away from the main relayer application, besides any overlapping decision logic the main relayer application also implements.
Scope
This is an umbrella ticket tracking distinct stages of developing this design. Development is split into the following stages:
Discussion and alternatives
Include a description of the changes to be made to the code along with alternatives
that were considered, including pro/con analysis where relevant.
Open questions
How much decision logic should the main relayer implement directly?
Option 1:
The main relayer application implements only basic error handling
The default Decider implements the existing "correctness" based existing ShouldSendMessage logic.
Runner scripts are shipped that enable one-click runs of the relayer+Decider system
Option 2:
The main relayer application implements the existing "correctness" based existing ShouldSendMessage logic.
The default Decider may be left empty
The system can be run with parity to the existing implementation by running the main relayer application on its own
Option 1 is less opinionated on the main relayer application side, but has a more complex deployment, as the Decider is required in order to achieve parity with the existing implementation
Option 2 is more opinionated, but preserves the existing behavior without any deployment changes
The text was updated successfully, but these errors were encountered:
Context
Research on #335 is complete, and the following design has been settled on:
Scope
This is an umbrella ticket tracking distinct stages of developing this design. Development is split into the following stages:
Discussion and alternatives
Include a description of the changes to be made to the code along with alternatives
that were considered, including pro/con analysis where relevant.
Open questions
ShouldSendMessage
logic.ShouldSendMessage
logic.The text was updated successfully, but these errors were encountered: