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, if a deal doesn't report a new status after --dealsfinalitytimeout, it will be considered failed. For example, if a deal is reported Sealing for more than 3 days without any status update, then most probably something bad happened and we should abort watching this deal.
This has some problems:
If Powergate is restarted, the timeout will start from zero again. So not entirely ideal.
Even if we take as a starting point the time the Job or Deal was created (which would be a good improvement), this doesn't account the fact that the Lotus node could be lagged in the syncing process and not be reporting the latest real status; which ultimately is a problem.
Looks to me the best solution is consider as the finality timeout the StartDealEpoch that was set when the deal was created. This is a hard-limit for the miner to publish the deal on-chain. If the miner fails to do that in time, the network would reject the deal. So looks like this should be the best way to solve this timeout challenge.
Doing it this way will work correctly if the Lotus node has fall behind, since we're using a timing relative to network age, and not absolute time. If for some reason Lotus takes a bunch of time to sync, the timeout will wait accordingly too.
The text was updated successfully, but these errors were encountered:
jsign
changed the title
ffs/scheduler: deal finality relative to startepoch
ffs/scheduler: deal finality considering deal start epoch
Oct 5, 2020
Currently, if a deal doesn't report a new status after
--dealsfinalitytimeout
, it will be considered failed. For example, if a deal is reported Sealing for more than 3 days without any status update, then most probably something bad happened and we should abort watching this deal.This has some problems:
Looks to me the best solution is consider as the finality timeout the StartDealEpoch that was set when the deal was created. This is a hard-limit for the miner to publish the deal on-chain. If the miner fails to do that in time, the network would reject the deal. So looks like this should be the best way to solve this timeout challenge.
Doing it this way will work correctly if the Lotus node has fall behind, since we're using a timing relative to network age, and not absolute time. If for some reason Lotus takes a bunch of time to sync, the timeout will wait accordingly too.
The text was updated successfully, but these errors were encountered: