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

fix(replay): Ensure we do not try to flush when we force stop replay #8783

Merged
merged 7 commits into from
Aug 10, 2023

Conversation

mydea
Copy link
Member

@mydea mydea commented Aug 10, 2023

In our stop() method, we always tried to force a final flush when in session 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.

@mydea mydea requested a review from billyvg August 10, 2023 09:40
@mydea mydea self-assigned this Aug 10, 2023
@@ -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' });
Copy link
Member Author

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?

@github-actions
Copy link
Contributor

github-actions bot commented Aug 10, 2023

size-limit report 📦

Path Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped) 75.1 KB (+0.34% 🔺)
@sentry/browser (incl. Tracing) - Webpack (gzipped) 31.11 KB (0%)
@sentry/browser - Webpack (gzipped) 21.81 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped) 69.71 KB (+0.24% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped) 28.16 KB (+0.03% 🔺)
@sentry/browser - ES6 CDN Bundle (gzipped) 20.18 KB (+0.04% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed) 219.8 KB (+0.34% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed) 84.69 KB (+0.03% 🔺)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed) 59.86 KB (+0.04% 🔺)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped) 31.02 KB (+0.03% 🔺)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped) 65.3 KB (+0.39% 🔺)
@sentry/react - Webpack (gzipped) 21.84 KB (0%)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped) 92.92 KB (+0.3% 🔺)
@sentry/nextjs Client - Webpack (gzipped) 50.64 KB (+0.06% 🔺)

@mydea mydea force-pushed the fn/fix-failed-flush branch 2 times, most recently from 009ce34 to baa242e Compare August 10, 2023 11:10
await advanceTimers(160_000);

expect(mockFlush).toHaveBeenCalledTimes(2);
expect(mockFlush).toHaveBeenCalledTimes(1);
Copy link
Member Author

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.

@mydea mydea merged commit fc7344f into develop Aug 10, 2023
73 checks passed
@mydea mydea deleted the fn/fix-failed-flush branch August 10, 2023 14:54
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.

None yet

2 participants