-
Notifications
You must be signed in to change notification settings - Fork 9
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
Make sure that we always use the instrumentation listener #614
Make sure that we always use the instrumentation listener #614
Conversation
🦋 Changeset detectedLatest commit: 8f26f52 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
// otherwise the reporter would get notified multiple times about the same steps | ||
if (patchedTestInfos.has(testInfo)) { | ||
return use(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Essentially, this PR ensures that we attach the instrumentation listener in this scenario while avoiding patching the test info twice.
To do that I introduced cached getFixtureState
since we need to use the same expectSteps
and ignoredSteps
sets across doubled fixture runs like this.
And I made sure that we only create a single WS connection here to spare some resources and that both of those fixture runs await the connection properly. That said, the WS code will hopefully go away from this fixture soon - I'm working on that separately.
/release-pr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just kind of skimmed this
|
||
ws.on("open", () => deferred.resolve(ws)); | ||
ws.on("error", error => deferred.reject(error)); | ||
// TODO: close WS connections on test end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I always assume that "TODO" comments without Linear tasks never be fixed (because I see so many of them in the code) – Prefer if we're going to add these that we add issues along with them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just got moved from the old place in the code. It will hopefully be removed soon because I'm working on ditching the WS-based communication altogether from this fixture.
No description provided.