fix: sealing pipeine: Release assigned deals on snapdeals abort

[magik6k]

Related Issues

Proposed Changes

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[Reiers]

CC sectors that been upgraded then aborted SectorRetrySubmitReplicaUpdate due to whatever reason during sealing will not snap-upgrade again.
The message in miner logs are the same sector had no deals and SectorRevertUpgradeToProving.

90.	2022-04-09 20:50:00 +0200 CEST:	[event;sealing.SectorRetrySubmitReplicaUpdate]	{"User":{}}
91.	2022-04-09 20:51:17 +0200 CEST:	[event;sealing.SectorSubmitReplicaUpdateFailed]	{"User":{}}
92.	2022-04-09 20:52:17 +0200 CEST:	[event;sealing.SectorRetrySubmitReplicaUpdate]	{"User":{}}
93.	2022-04-09 20:52:17 +0200 CEST:	[event;sealing.SectorSubmitReplicaUpdateFailed]	{"User":{}}
94.	2022-04-09 20:53:17 +0200 CEST:	[event;sealing.SectorAbortUpgrade]	{"User":{}}
	triggered by user
95.	2022-04-09 20:53:17 +0200 CEST:	[event;sealing.SectorRetrySubmitReplicaUpdate]	{"User":{}}
96.	2022-04-09 21:14:48 +0200 CEST:	[event;sealing.SectorRevertUpgradeToProving]	{"User":{}}
97.	2022-11-08 19:53:20 +0100 CET:	[event;sealing.SectorMarkForUpdate]	{"User":{}}
98.	2022-11-08 21:23:00 +0100 CET:	[event;sealing.SectorStartCCUpdate]	{"User":{}}
99.	2022-11-08 21:23:00 +0100 CET:	[event;sealing.SectorStartPacking]	{"User":{}}
100.	2022-11-08 21:23:00 +0100 CET:	[event;sealing.SectorAbortUpgrade]	{"User":{}}
	sector had no deals
101.	2022-11-08 21:23:00 +0100 CET:	[event;sealing.SectorRevertUpgradeToProving]	{"User":{}}

Sectors that have been aborted by the user before the sector snap upgrade sealing cycle, can now be upgraded again on this branch.

9.	2021-10-05 19:51:14 +0200 CEST:	[event;sealing.SectorFinalized]	{"User":{}}
10.	2021-10-05 19:51:14 +0200 CEST:	[event;sealing.SectorCommitSubmitted]	{"User":{"Message":{"/":"bafy2bzacea55rcaykso3adlbuhwde6wugqrfj5srdglsz3l4i7vwvkic2vjzu"}}}
11.	2021-10-05 19:55:00 +0200 CEST:	[event;sealing.SectorProving]	{"User":{}}
12.	2021-10-05 19:55:00 +0200 CEST:	[event;sealing.SectorFinalized]	{"User":{}}
13.	2022-11-06 11:58:52 +0100 CET:	[event;sealing.SectorMarkForUpdate]	{"User":{}}
14.	2022-11-08 19:34:47 +0100 CET:	[event;sealing.SectorAbortUpgrade]	{"User":{}}

Full report tmr, on "will the deal roll over to the next one if sector upgrade fails or be stuck in staged"

[magik6k]

Yeah.. this behavior makes sense, and I guess warrants being fixed. See

// todo: return to the sealing queue (this is extremely unlikely to happen)
pp.accepted(sector.SectorNumber, 0, xerrors.Errorf("sector %d entered packing state early", sector.SectorNumber))

in cleanupAssignedDeals.

I guess we can still merge this PR as it technically should be improving things, and implement deal-recycling logic in a separate PR