Skip to content

test: add success e2e tests for stream processing commands MONGOSH-2127 #2459

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

malexandert
Copy link

@malexandert malexandert commented May 27, 2025

Going to open this up early since I'm running into flakiness on Evergreen and I'm not entirely sure how to resolve it. The error I see coming up most frequently is something like

 [2025/06/03 15:15:41.723] FAILURE:  ()
 [2025/06/03 15:15:41.723] [Timed out 10000ms] expected prompt
 [2025/06/03 15:15:41.723]       + expected - actual
 [2025/06/03 15:15:41.723]       -Current Mongosh Log ID:	683f4860c22a17067f8d8250
 [2025/06/03 15:15:41.723]       -Connecting to:		mongodb://<credentials>@atlas-stream-67ec5d03a32c2e2a2d533eaa-5ml8o.virginia-usa.a.query.mongodb-dev.net/?directConnection=true&tls=true&appName=<REDACTED:notary_signing_key_name>+2.4.0
 [2025/06/03 15:15:41.723]       -Using MongoDB:		Atlas Stream Processing
 [2025/06/03 15:15:41.723]       -Using Mongosh:		2.4.0
 [2025/06/03 15:15:41.723]       -
 [2025/06/03 15:15:41.723]       -For <REDACTED:notary_signing_key_name> info see: https://www.mongodb.com/docs/mongodb-shell/
 [2025/06/03 15:15:41.723]       -
 [2025/06/03 15:15:41.723]       -AtlasStreamProcessing> Atlas Stream Processor: spi683f4861393f8cbf8e529491
 [2025/06/03 15:15:41.723]       -AtlasStreamProcessing> [prompt search starts here]
 [2025/06/03 15:15:41.723]       +/^([^<>]*> ?)+$/m
 [2025/06/03 15:15:41.723]       
 [2025/06/03 15:15:41.723] AssertionError [ERR_ASSERTION]: expected prompt
 [2025/06/03 15:15:41.723]     at new AssertionError (node:internal/assert/assertion_error:454:5)
 [2025/06/03 15:15:41.723]     at /data/mci/b09c072f17e8644b70e629d572a0c179/src/packages/e2e-tests/test/test-shell.ts:238:17
 [2025/06/03 15:15:41.723]     at eventually (/data/mci/b09c072f17e8644b70e629d572a0c179/src/testing/eventually.ts:18:13)
 [2025/06/03 15:15:41.723]     at async TestShell.waitForPrompt (test/test-shell.ts:214:5)
 [2025/06/03 15:15:41.723]     at async TestShell.executeLine (test/test-shell.ts:300:5)
 [2025/06/03 15:15:41.723]     at async Context.<anonymous> (test/e2e-streams.spec.ts:136:27)

which, when referring to this call, implies that the command either didn't run at all or it took too long to return a response? I'm not able to repro the failure when running the test locally, so I'm wondering if you have any ideas on how to proceed

@malexandert malexandert changed the title test: add success e2e tests for stream processing commands MONGOSH-2127 WIP test: add success e2e tests for stream processing commands MONGOSH-2127 May 27, 2025
@malexandert malexandert force-pushed the MONGOSH-2127 branch 5 times, most recently from 9c21f46 to 9ba0d55 Compare May 30, 2025 19:54
@malexandert malexandert changed the title WIP test: add success e2e tests for stream processing commands MONGOSH-2127 test: add success e2e tests for stream processing commands MONGOSH-2127 Jun 4, 2025
@malexandert malexandert marked this pull request as ready for review June 4, 2025 19:14
@malexandert malexandert requested review from addaleax and drichmdb June 4, 2025 19:14
@malexandert
Copy link
Author

welp, tests are just failing now because dev is having issues. I'll restart the tasks later once that's sorted

@malexandert
Copy link
Author

Ok from a bit more testing, it seems like bumping the timeout for waitForPrompt specifically does smooth out some of the flakes. Gonna see if I can try and minimize the bumped timeouts and then update this PR

@addaleax
Copy link
Collaborator

addaleax commented Jun 6, 2025

Ok from a bit more testing, it seems like bumping the timeout for waitForPrompt specifically does smooth out some of the flakes. Gonna see if I can try and minimize the bumped timeouts and then update this PR

Yeah, this seems like it would be fine to apply this locally here – is it expected that sp.start() takes a long amount of time, or is it supposed to return fairly quickly?

expect(startResult).to.include('{ ok: 1 }');

// sleep for a bit to let the processor do stuff
await sleep(500);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it make sense to instead wait using eventually() for the assertion below on the first countDocuments()'s return value to be true? That should help with avoiding flakiness from this bit

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.

2 participants