-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix(replay): Ensure we do not try to flush when we force stop replay #8783
Conversation
@@ -1214,7 +1214,7 @@ export class ReplayContainer implements ReplayContainerInterface { | |||
|
|||
// Stop replay if over the mutation limit | |||
if (overMutationLimit) { | |||
void this.stop('mutationLimit'); | |||
void this.stop({ reason: 'mutationLimit', forceFlush: this.recordingMode === 'session' }); |
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.
For this case we still want to flush I guess? The integration test failed for this, and I guess it is OK to do a final flush here to have details on why this was stopped - we do not add the large mutations anyhow yet, so should be fine?
size-limit report 📦
|
009ce34
to
baa242e
Compare
await advanceTimers(160_000); | ||
|
||
expect(mockFlush).toHaveBeenCalledTimes(2); | ||
expect(mockFlush).toHaveBeenCalledTimes(1); |
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 also shows the incorrect behavior, it was flushing twice before even though it shouldn't have.
baa242e
to
bc1b883
Compare
dc1b624
to
81ed9bd
Compare
In our
stop()
method, we always tried to force a final flush when insession
mode.However, that may lead to weird behaviour when we internally
stop()
due to a failure - e.g. think a send replay request fails, we do not want to force a flush again in that case.Note that in tests this seems to be generally passing because
flush()
usually has a running_flushLock
at this time and thus does not attempt to flush again immediately but only schedules a flush later. I added a test that properly failed for this before and is now fixed.