-
- Notifications
You must be signed in to change notification settings - Fork 1.7k
ref(core): Add weight tracking logic to browser logs/metrics #17901
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
base: develop
Are you sure you want to change the base?
Conversation
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.
|
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.
LGTM
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.
Nice refactor, thanks for adding!
packages/core/src/client.ts Outdated
): void { | ||
// @ts-expect-error - TypeScript can't narrow generic hook types to match specific overloads, but we know this is type-safe | ||
client.on(flushHook, () => { | ||
client[weightProperty] = 0; |
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.
m/h: does still work in our CDN bundles where we mangle private _
-prefixed names?
l: Not particularly a fan of extracting this to a function and then accessing private members. Is there a reason for this over adding a private method to the Client class?
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.
alternatively, could we keep the weight property (+whatever else) as variables within the closure of setupWeightBasedFlushing
?
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.
yeah using closure variables is way nicer. Lemme refactor.
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.
LGTM
We've seen some cases where our browser logs are hitting size limits. I suspect this is because we don't have any robust size tracking mechanisms in the browser sdk.
This refactors our log flushing mechanisms in the SDK to unify everything between the browser client and server runtime client. This also means the browser SDK gets a weight tracking mechanism for buffering, which should help with making sure we don't run into size issues with logs.
Given metrics has the same issue, I included it in this refactor.