Skip to content
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: capture plugin errors during ready phase #5681

Merged
merged 1 commit into from
May 29, 2024

Conversation

eduardoboucas
Copy link
Member

Summary

Follow-up to #5679. Extracts the logic for registering and unregistering the listeners into a separate method, which is now called for both the load and the ready phases of the plugin initialisation.

Sadly I cannot write a test that asserts the behaviour for the ready phase because I can't find a way to produce that locally. Since we use the same method as load, our existing tests gives us some coverage.

@eduardoboucas eduardoboucas requested review from a team as code owners May 28, 2024 16:20
Copy link
Contributor

This pull request adds or modifies JavaScript (.js, .cjs, .mjs) files.
Consider converting them to TypeScript.

eventName: string,
featureFlags: FeatureFlags,
) => {
if (!featureFlags.netlify_build_plugin_system_log) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I failed to mention this on the last PR, but I think this flag should be called netlify_build_plugin_system_log_errors or similar. The current name makes it sound like it's related to #5391. Having said that, the flag is super short-lived, so it shouldn't matter too much.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I totally see that. Let's hope we can kill the flag soon.

return { childProcess }
} catch (error) {
if (featureFlags.netlify_build_plugin_system_log) {
// Wait for stderr to be flushed.
await pSetTimeout(0)
Copy link
Contributor

@Skn0tt Skn0tt May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would setImmediate also work here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would, yes. Just trying to stay as conservative as possible with this change.

Copy link
Contributor

@Skn0tt Skn0tt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks good. Left some small comments. I'll play around locally to see if I can write a test for the ready event.

@eduardoboucas eduardoboucas merged commit afb6816 into main May 29, 2024
37 checks passed
@eduardoboucas eduardoboucas deleted the fix/capture-stderr-ready branch May 29, 2024 08:22
This was referenced Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants