-
Notifications
You must be signed in to change notification settings - Fork 2
[WIP] Further identifiers in tests #56
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
[WIP] Further identifiers in tests #56
Conversation
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
e2a78f7
to
c4bab5f
Compare
ae9d9aa
to
f3011cf
Compare
This allows us to use "run repeatedly" without the runs interfering with each other. wip adding test UUID to logs this isn't quite right — we need to be able to do client2 and have the ID there too (probably should bake the test into the context) also Test overlaps with Swift Testing terminology now
33e2edf
to
08639a8
Compare
08639a8
to
e21ad82
Compare
- number of concurrent Realtime instances - when monitorConnectionThenCloseAndFinishAsync fails (to see whether it's actually failing the test when it should be)
asked Cursor to write this trait that limits concurrency this is because there seem to be issues with running concurrent tests (hangs, and failures that I think are because of it exercising edge cases in the tests, but also Realtime's "Error 40111 - account restricted (connection limit exceeded)" and connection timeouts) my logging suggests that we have up to 100 Realtime instances active at a time I was going to just make things .serialized for now but that makes the test suite really slow (like 4 minutes) so I hoped we could find a middle ground I tried making it a suite trait that has isRecursive: true (which I thought was the default which is why I made those earlier changes to the fixtures trait) but it doesn't seem to be. I've however observed this hanging at least once locally so won't be taking this forward for now (need to get the test suite fixed and have a time pressure)
Mistake in 70306a0. Correct approach copied from "Objects.createCounter sends COUNTER_CREATE operation" test.
Wait until we're sure that GC of an entry should have occurred, regardless of clock skew. Also fix what may have been a bug in 792683d where we may not wait for as many GC cycles as we intended to (because of counting AsyncStream buffered values).
e21ad82
to
478f957
Compare
Some handy stuff for debugging tests; needs tidying up