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
Currently, we still sometimes experience issues when cw pools migrate despite adding fault tolerance.
As one of the approaches to mitigate, we should detect cw pool migrations via SDK state-streaming and push them into SQS, replacing code ID in the config.
There are multiple approaches we could pursue:
Write a state entry migration in chain state and then delete it to trigger state-streaming. Dynamically update SQS
Do transaction/message parsing (expensive)
Monitor wasmd state migrations (complex)
Proposing option 1 as the migrations are not expected to be triggered frequently, and we will clean up the state while triggering the necessary component.
This would also simplify the architecture as a whole
As part of this effort, we will have to synchronize the cosmwasm pool config with a read-write lock.
DoD
Add logic to update a migration state-entry
Dynamically propagate it to SQS ingest
Syncronize and update the cosmwasm code id config
Unit test
Locally test against mainnet state
The text was updated successfully, but these errors were encountered:
Currently, we still sometimes experience issues when cw pools migrate despite adding fault tolerance.
As one of the approaches to mitigate, we should detect cw pool migrations via SDK state-streaming and push them into SQS, replacing code ID in the config.
There are multiple approaches we could pursue:
Proposing option 1 as the migrations are not expected to be triggered frequently, and we will clean up the state while triggering the necessary component.
This would also simplify the architecture as a whole
As part of this effort, we will have to synchronize the cosmwasm pool config with a read-write lock.
DoD
The text was updated successfully, but these errors were encountered: