-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(op-batcher): altda->ethda failover #13
base: feat--multiframe-altda-channel
Are you sure you want to change the base?
feat(op-batcher): altda->ethda failover #13
Conversation
adfa7ce
to
61d7578
Compare
At the high level, it usually takes us about 1 hour to fix the problem |
@@ -130,6 +134,10 @@ func (s *FakeDAServer) HandleGet(w http.ResponseWriter, r *http.Request) { | |||
|
|||
func (s *FakeDAServer) HandlePut(w http.ResponseWriter, r *http.Request) { | |||
time.Sleep(s.putRequestLatency) | |||
if s.failoverCount > 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the point to decrement failoverCount, then actually handle the put
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it just to simplify testing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we only want to cause a temporary failure. So this way we can say "pretend you are down for the next failoverCount calls", and after that the system becomes normal again.
op-e2e/system/altda/failover_test.go
Outdated
) | ||
|
||
// TestBatcher_FailoverToEthDA_FallbackToAltDA tests that the batcher will failover to ethDA | ||
// if the da-server returns 503, and then fallback to altDA once altDA is available again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we always try altda first for every dispersal, then retry for non-altDA after sufficient retry. Wording seems odd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed the wording: 6928901
|
||
countEthDACommitment := uint64(0) | ||
|
||
// Most likely, sequence of blocks will be: altDA, ethDA, ethDA, altDA, altDA, altDA. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why most likely? And why two ethDA in a row, because we set failoverCount=2, but why altDA in the beginning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check this new comment: 71d8697
1a84f49
to
bb0ba93
Compare
in TestBatcher_FailoverToEthDA_FallbackToAltDA
71d8697
to
a881df5
Compare
DON'T MERGE!
Plan is to upstream this to op's repo. Created here to get review from the team first.
This PR builds on top of the feat--multiframe-altda-channel changes (already upstreamed to op's repo, waiting for review there)
It contains 2 commits:
Right now failover is done to calldata txs because that was trivial whereas failing over to blobs or their auto mode that switches between blobs and calldata would need a nontrivial refactor and some thinking. Not sure its worth putting effort into this atm given that the whole point of failover is that it should happen very rarely and also not last very long, but let me know if you guys think otherwise.