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

fix(cli): hangs on retrieving notices #19967

Merged
merged 5 commits into from
Apr 19, 2022
Merged

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Apr 19, 2022

In an environment where DNS resolution works but network packets may be
dropped, the CLI can hang for up to 15 minutes trying to refresh
notices. We tried to set a timeout of 3 seconds on this, but did it in a
way that didn't work.

Turns out that the request.on('timeout') event in NodeJS doesn't actually stop
the request: it just notifies the listener that it's been a long time
since we saw network bytes, leaving the listener to do with that
what they want (potentially show a dialog box to a waiting user or
whatever). In our case, we had to do an additional request.destroy()
to actually stop the request.

Without doing this, the Promise would resolve correctly and the CLI
would continue, but the actual HTTP request would still be going on
in the background, preventing Node from shutting down.

This PR also changes the behavior of reporting a download failure: it
used to be that we would successfully resolve to a [] response if
the HTTP request failed (which would then be cached). Instead, after
this change we reject the Promise if anything goes wrong, so that the
next invocation will try again.

Fixes #19542.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

In an environment where DNS resolution works but network packets may be
dropped, the CLI can hang for up to 15 minutes trying to refresh
notices. We tried to set a timeout of 3 seconds on this, but did it in a
way that didn't work.

Turns out that the `request.on('timeout')` event in NodeJS doesn't actually stop
the request: it just notifies the listener that it's been a long time
since we saw network bytes, leaving the listener to do with that
what they want (potentially show a dialog box to a waiting user or
whatever). In our case, we had to do an additional `request.destroy()`
to actually stop the request.

Without doing this, the Promise would resolve correctly and the CLI
would continue, but the actual HTTP request would still be going on
in the background, preventing Node from shutting down.

This PR also changes the behavior of reporting a download failure: it
used to be that we would successfully resolve to a `[]` response if
the HTTP request failed (which would then be cached). Instead, after
this change we reject the Promise if anything goes wrong, so that the
next invocation will try again.

Fixes #19542.
@rix0rrr rix0rrr requested a review from a team April 19, 2022 12:37
@rix0rrr rix0rrr self-assigned this Apr 19, 2022
@gitpod-io
Copy link

gitpod-io bot commented Apr 19, 2022

@aws-cdk-automation aws-cdk-automation requested a review from a team April 19, 2022 12:37
@github-actions github-actions bot added bug This issue is a bug. p2 labels Apr 19, 2022
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Apr 19, 2022
@rix0rrr rix0rrr added the pr/do-not-merge This PR should not be merged at this time. label Apr 19, 2022
@rix0rrr rix0rrr removed the pr/do-not-merge This PR should not be merged at this time. label Apr 19, 2022
@@ -341,7 +340,7 @@ async function initCommandLine() {
try {
return await main(cmd, argv);
} finally {
await version.displayVersionMessage();
// await version.displayVersionMessage();
Copy link
Contributor

Choose a reason for hiding this comment

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

This meant to remain commented? (added dnm again)

@mergify
Copy link
Contributor

mergify bot commented Apr 19, 2022

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@MrArnoldPalmer MrArnoldPalmer added the pr/do-not-merge This PR should not be merged at this time. label Apr 19, 2022
@rix0rrr rix0rrr removed the pr/do-not-merge This PR should not be merged at this time. label Apr 19, 2022
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
  • Commit ID: c3993f1
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Apr 19, 2022

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit daeeafa into master Apr 19, 2022
@mergify mergify bot deleted the huijbers/notices-timeout branch April 19, 2022 16:27
StevePotter pushed a commit to StevePotter/aws-cdk that referenced this pull request Apr 27, 2022
In an environment where DNS resolution works but network packets may be
dropped, the CLI can hang for up to 15 minutes trying to refresh
notices. We tried to set a timeout of 3 seconds on this, but did it in a
way that didn't work.

Turns out that the `request.on('timeout')` event in NodeJS doesn't actually stop
the request: it just notifies the listener that it's been a long time
since we saw network bytes, leaving the listener to do with that
what they want (potentially show a dialog box to a waiting user or
whatever). In our case, we had to do an additional `request.destroy()`
to actually stop the request.

Without doing this, the Promise would resolve correctly and the CLI
would continue, but the actual HTTP request would still be going on
in the background, preventing Node from shutting down.

This PR also changes the behavior of reporting a download failure: it
used to be that we would successfully resolve to a `[]` response if
the HTTP request failed (which would then be cached). Instead, after
this change we reject the Promise if anything goes wrong, so that the
next invocation will try again.

Fixes aws#19542.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. contribution/core This is a PR that came from AWS. p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

(pipelines): SelfMutate loads notices by default
4 participants