-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
fix:sealing-fsm:wait mutable fsm state for immutable sector upgrade error #9598
Conversation
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.
Briefly skimming this it looks like it should work.
An itest shouldn't be that hard to write, basically start with sealing a sector, stop mining and manipulate which epoch we're at much like as is done in wdpost tests.
dlineEpochsRemaining := dlinfo.NextOpen() - ts.Height() | ||
if sectorDeadlineOpen { | ||
// sleep for remainder of deadline | ||
time.Sleep(time.Duration(build.BlockDelaySecs) * time.Second * time.Duration(dlineEpochsRemaining)) |
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.
Should respect ctx.Context() here
From last nights, stress test:
Every sector within the deadlines ended up in a
This morning, the sectors that entered the state - where still in a WaitMutable state.
Active status YES:
No difference in the sector log comparing the ones that was Active or Not. Status right now,
|
Success ! Non stuck, no faulty, no errors:
|
} | ||
|
||
select { | ||
case <-time.After(waitTime): |
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.
Nit: For integration tests we'll want to replace this sleep with events.ChainAt
as in those time isn't really related to height
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.
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.
The events thing looks reasonable
log.Errorf("handleWaitMutable: api error, not proceeding: %+v", err) | ||
return nil |
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 probably want to sleep a bit (~60s) and loop around, this can happen when the API is disconnected, which.. can happen
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.
Makes a ton of sense. Becuase I'm just copying this pattern from all over the place inside the fsm I think this issue is out of scope for this PR and should be handled across the board for all fsm states. Filed #9637 for this
Related Issues
#8496
Proposed Changes
WaitMutable state that nicely waits for deadline to be over before continuing
Additional Info
No tests yet so it's probably broken. But this is a good place to start from
Checklist
Before you mark the PR ready for review, please make sure that:
<PR type>: <area>: <change being made>
fix: mempool: Introduce a cache for valid signatures
PR type
: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, testarea
, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps