-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(logs): Add internal replay_is_buffering
flag
#17752
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
Conversation
Integration & { | ||
getReplayId: (onlyIfSampled?: boolean) => string; | ||
getRecordingMode: () => 'session' | 'buffer' | undefined; |
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.
@AbhiPrasad I kept the inlined types here, I assume we have no access to the replay types in core?
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.
We could extract the types into core to make this a more "public" API, it also helps to keep this consistent. I'd just do it in another PR though.
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
4fb9c51
to
2238e52
Compare
Adds a flag
replay_is_buffering
for identifying cases where the replayId is attached but the replay itself might never arrive in Sentry.ref #17676