ref(core): Add weight tracking logic to browser logs/metrics#17901
ref(core): Add weight tracking logic to browser logs/metrics#17901AbhiPrasad merged 4 commits intodevelopfrom
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.
|
chargome
left a comment
There was a problem hiding this comment.
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.
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.
alternatively, could we keep the weight property (+whatever else) as variables within the closure of setupWeightBasedFlushing?
There was a problem hiding this comment.
yeah using closure variables is way nicer. Lemme refactor.
…ry#17901) 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. <img width="1251" height="513" alt="image" src="https://github.com/user-attachments/assets/2364b984-2b53-4c6a-89e5-0a0e20fa3246" /> 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.
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.