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

test(codecatalyst): only fail test if message is more than a minute off. #6265

Merged
merged 2 commits into from
Dec 18, 2024

Conversation

Hweinstock
Copy link
Contributor

@Hweinstock Hweinstock commented Dec 17, 2024

Problem

fix #6213

Solution

  • The important part of this test is that the message comes after being inactive. If the message comes slightly early/late, that is okay. If it doesn't come at all, then we have problems and should fail.
  • Pass test if message comes within a minute of expected.

Alternatives

  • skip the test.
  • Re-do test setup since its flaky.

  • Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
  • Your code changes must meet the guidelines in CONTRIBUTING.md.

License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

@Hweinstock
Copy link
Contributor Author

/runIntegrationTests

@Hweinstock Hweinstock marked this pull request as ready for review December 17, 2024 20:14
@Hweinstock Hweinstock requested a review from a team as a code owner December 17, 2024 20:14
assert.ok(
Math.abs(actualMessages[i].minute - expected.minute) <= 1,
`Expected to be within 60 seconds of minute ${expected.minute}, but instead was at minute ${actualMessages[i].minute}`
)
assert.deepStrictEqual(actualMessages[i], expected)
Copy link
Contributor

Choose a reason for hiding this comment

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

should drop this line, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was intending this line to check if the time the message popped up was within a minute of the expected time. Do you think it would be better to not check the time the message came up at all?

Copy link
Contributor

Choose a reason for hiding this comment

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

If we don't remove "something", the test will still fail, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm making the check more lenient. The logs in the issue show that the message is popping up at minute 54, when we expect it at 55. If that happens, the current logic should pass now since its within one minute of the expected time.

Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand correctly he's confused about why we aren't removing

assert.deepStrictEqual(actualMessages[i], expected)

since

assert.ok(Math.abs(actualMessages[i].minute - expected.minute) <= 1, 'Expected to be within 60 seconds of minute ${expected.minute}, but instead was at minute ${actualMessages[i].minute}')

is meant to replace it. If we kept the original check (assert.deepStrictEqual(actualMessages[i], expected)), wouldn't that check still fail since that piece of code is also checking the time?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh my bad. Yes, we should remove that line. Sorry was looking at the wrong line and totally missed it.

@justinmk3 justinmk3 merged commit 8708c52 into aws:master Dec 18, 2024
26 of 28 checks passed
@Hweinstock Hweinstock deleted the integ/devEnv/withinAMinute branch December 18, 2024 17:32
karanA-aws pushed a commit to karanA-aws/aws-toolkit-vscode that referenced this pull request Jan 17, 2025
## Problem
fix aws#6213

## Solution
- The important part of this test is that the message comes after being inactive. If the message comes slightly early/late, that is okay. If it doesn't come at all, then we have problems and should fail. 
- Pass test if message comes within a minute of expected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

unreliable test: shows warning 5 minutes before shutdown for 60 minute timeout
3 participants