Uh oh!
There was an error while loading. Please reload this page.
feat(core,cloudflare): Add dispose method to CloudflareClient for proper cleanup - #19364
Closed
JPeer264 wants to merge 3 commits into
Closed
feat(core,cloudflare): Add dispose method to CloudflareClient for proper cleanup#19364JPeer264 wants to merge 3 commits into
JPeer264 wants to merge 3 commits into
Conversation
Contributor
Codecov Results 📊Generated by Codecov Action |
Contributor
size-limit report 📦
|
Contributor
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.
|
…ent for proper cleanup
JPeer264force-pushed
the
jp/dispose-client
branch
from
February 17, 2026 16:37
8ba7238 to
d43b738Compare…lareClient for proper cleanup
… CloudflareClient for proper cleanup
JPeer264
commented
Feb 24, 2026
MemberAuthor
Closing as this will be split up as memory profiling in GHA are not working as expected and need more clarification |
JPeer264 added a commit
that referenced
this pull request
Mar 2, 2026
…19506) closes#19475 closes [JS-1785](https://linear.app/getsentry/issue/JS-1785/investigate-memory-leaks-in-cloudflare) This is a way to dispose the client entirely. Every request in Cloudflare Workers create their own client. Once the request is done the client would stay in memory forever, unless we `dispose` it after every request. We also have to wait until all `waitUntil`s are finished, otherwise we would loose these traces. The `dispose()` method got added on purpose into the core client, as the `getCurrentClient()` would return a `Client`. The `dispose()` method actually only has functionality inside the `ServerRuntimeClient`, as only the server would need this functionality. There is still a leak in one of the default integrations, but when running load tests against [the reproduction repo](https://github.com/JPeer264/temp-cloudflare-leak) and setting `defaultIntegrations: false`, then no leak is happening. FWIW there will be a separate PR for adding a MemoryProfiler as seen in #19364, to prevent this memory leak in the future.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
similar to #19336 - this PR is here to reduce the memory footprint and memory leaks for Cloudflare.
This adds two things:
MemoryProfiler
A way to measure the heap profile in Playwright (kudos to @aishahsofea for this idea as written up here) - we could create a separate PR for it if you want, but it won't be used anywhere that is why I left it in this PR
Dispose Client
A way to dispose the client entirely. Every request in Cloudflare Workers create their own client. However, the client stays in-memory and the isolate might not be evicted correctly. As of now the memory footprint got reduced from ~1mb to ~730kb after 50 requests. The goal is to reduce the memory footprint even further - the test currently makes sure that future code won't increase memory for Cloudflare by accident (that is where the
MemoryProfilercomes in handy).The
dispose()method got added on purpose into the core client, as this might come in handy for future integrations like the@sentry/honoSDK