feat: reconciliation rule blocking timed out/failed futures #428
Conversation
If a future has previously timed out or failed (not just failed at simulation). Then the user must wipe the future with the wipe command before rerunning. We enforce this with a reconciliation check. This check comes after the future level reconciliation checks (a design decision we may revisit - could it just be a standard rule?). Resolves #412.
| if (reconciliationFailures.length === 0) { | ||
| reconciliationFailures = this._reconcileNoErroredFutures(deploymentState); | ||
| } | ||
|
|
||
| // TODO: Reconcile sender of incomplete futures. |
There was a problem hiding this comment.
| // TODO: Reconcile sender of incomplete futures. |
Not relevant to this PR, but we already did this.
Agreed. I will merge. I initially had it as a post-reconciliation check. But I then needed to answer the question, "what is the return result?". I picked validation, then changed my mind and went with reconciliation. At that point though it seemed odd to have a post reconciliation check that returned a reconciliation failure, rather than an additional rule in reconciliation. Happy to shift it out and improve the message, we just need to consider whether it should count as an additional phase and hence get a new return type. |
If a future has previously timed out or failed (not just failed at simulation). Then the user must wipe the future with the wipe command before rerunning.
We enforce this with a reconciliation check. This check comes after the future level reconciliation checks (a design decision we may revisit - could it just be a standard rule?).
Resolves #412.