Skip to content

fix(cli): hangs on retrieving notices#19967

Merged
mergify[bot] merged 5 commits intomasterfrom
huijbers/notices-timeout
Apr 19, 2022
Merged

fix(cli): hangs on retrieving notices#19967
mergify[bot] merged 5 commits intomasterfrom
huijbers/notices-timeout

Conversation

@rix0rrr
Copy link
Copy Markdown
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
Copy Markdown

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
return await main(cmd, argv);
} finally {
await version.displayVersionMessage();
// await version.displayVersionMessage();
Copy link
Copy Markdown
Contributor

@MrArnoldPalmer MrArnoldPalmer Apr 19, 2022

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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