Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Website query API: Continue plugin installs on error #605
Website query API: Continue plugin installs on error #605
Changes from 14 commits
797dce0
71f32d9
c6fbe1f
38791f2
71b2467
486a632
bc803cd
5fb2d41
1281355
4681f81
4722601
69eb4af
978a3fa
c8467b1
06d7f26
df14575
4243e59
b32c27b
c7b7920
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
didResolve() === false
suggests the promise may still be pending. I wonder what would be a more descriptive name here.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.
It was tough to find a suitable naming for this
didResolve
function. I consulted MDN: Promise to see what the standard terminology is.In the end I settled on a verbose name
isSettledPromiseResolved
, to make it clear that it's checking an already settled promise for its resolved status.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.
If the
onStepCompleted
handler throws an error, thestepPromise?.reject(error);
will run. It would be nice to just rethrow that error so the API consumer may notice and correct it.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.
Instead of rethrowing, the two lines
stepStatus?.resolve(result)
andonStepCompleted
have been moved below the try/catch clause. If the latter throws (by the user or an unexpected error), it bubbles up to the API consumer, the caller ofCompiledBlueprint.run()
.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 wonder whether the failure consequences should be possible to specify per step type, e.g.
rm
could default to triggering a warning but not stopping the execution, whiledefineWpConfigConsts
would default to throwing an error and stopping the execution.There seem to be a hierarchy of control here:
It would be nice to stop the execution as soon as we know the failure is fatal. Imagine the first step of a work-intense Blueprint fails and we already know this is irrecoverable – stopping right then and there would spare the user 30s of waiting before learning about the error.
Code-wise, it could mean a logic similar to this:
Now, the
isFailureFatal
would need to know about both the step preference and the user preference, which means we need to provide developers with a way of overriding the default behavior on a granular, per-step basis.This PR introduces a decision point in the
onStepsCompleted
callback registered by the application calling thecompileBlueprint
function. I think it would be more useful to make that decision inside of a Blueprint. Imagine a live product demo. TheinstallPlugin
installing the demoed plugin is indispensable, but the next one installing a dev utility plugin can likely be skipped if it fails.Technically, this could mean introducing a new step-level property:
export type StepDefinition = Step & { progress?: { weight?: number; caption?: string; }; + onFailure: 'abort' | 'skip'; };
This would enable writing blueprints such as...
The default value could be
abort
. Each step handler would be able to override it, for example like this:The
compileStep()
function could then output the desired failure behavior:And this loop could handle it as follows:
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 wonder how the ideas above resonate with you @eliot-akira @dmsnell @bgrgicak
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 think it fits within the idea I had, which was to expose each to the application and let it decide.
we could provide default behaviors, which I think should be rare, and then if someone in userspace adds their own handler for the step, then they could take their own action.
or, we could expose our default handling to the callback and only if they implement the callback would we use theirs instead.
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 like this approach, it would at least help with development and while creating blueprints.
Personally, I love opinionated code that I can adjust, so I would go with having defaults for each step, but let users override them. Maybe even include a global override for all steps.
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.
Thank you for the detailed review and feedback. I'm starting to get a feel for the public interface that's shaping up.
I like the idea of adding to the
StepDefinition
a new propertyonFailure
, with valueabort
orskip
. That addresses the original issue that motivated this PR, which is to allow some plugins to be skipped if install fails, while still keeping plugins required by default (error on install fail).It makes sense for each step handler to have a default failure mode (
abort
orskip
), which can be overridden by the user.I'll get started on implementing the suggestions, and will either resolve each reviewed point or reply with any questions.
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.
Thank you so much @eliot-akira, you are the best!