-
Notifications
You must be signed in to change notification settings - Fork 28
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: add Held
status to exState status
#457
Conversation
2e24167
to
2441256
Compare
1b72bdc
to
ab02ffb
Compare
I am opting to leave the run logic until we are actually exposing strategies that can use held. |
Hold
status to exState statusHeld
status to exState status
@@ -217,6 +217,12 @@ function convertExecutionResultToEventResult( | |||
error: "Transaction reverted", | |||
}; | |||
} | |||
case ExecutionResultType.STRATEGY_HELD: { |
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.
Sorry for being repetitive, but held shouldn't be considered an error.
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.
I have added another event result (held), to allow mapping from held to a non-error result. And wired it through the UI.
packages/hardhat-plugin/src/utils/error-deployment-result-to-exception-message.ts
Outdated
Show resolved
Hide resolved
To support execution strategies returning `held` status in the future, we are adding it into the execution status of exStates. The return result of a deployment can now include a held property listing the futures that have been held and the reason for the hold. This is wired through to the ui as a new sort of Held result instead of treating it as success or failure. Resolves #451
54ed809
to
85d6973
Compare
To support execution strategies returning
hold
status in the future,we are adding it into the execution status of exStates.
Resolves #451
TODO