feat(core): add cloudflare flushing logic to core util by logaretm · Pull Request #18330 · getsentry/sentry-javascript

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm · 2025-11-25T16:51:18Z

I was working on investigating Next.js support on Cloudflare workers, and we aren't getting any traces or errors for a few reasons. One of the issues relevant to this PR is our flushing did not handle Cloudflare’s waitUntil unless passed explicitly.

This is not feasible within some platforms due to them abstracting away the handler entry away from the user (e.g: opennext).

So I dug around the runtime and found that it was possible to grab it via a symbol similar to VercelWaitUntil. The implementation here checks if it is available, and if it is, then it uses it.

This can be useful for many other SDKs as previously it was always required to pass the Cloudflare from the context around.

Note: that this doesn't fix the Next.js issues support completely as I still need to do some other fixes on the SDK level.

What I considered

I considered importing waitUntil from the cloudflare:workers, but it is tricky to include at the core level as an external, and also very weird to include in other SDKs.
Adding a wrapper around the Cloudflare opennext adapter to do this in Next.js SDK, but that's a larger effort that has a lot of DX implications, so I will leave that to another PR.

logaretm · 2025-11-25T16:59:21Z

Opened this too early, I will need to first investigate if this is available in all cloudflare workers environments or just opennext's because it seems like so which didn't occur to me.

Will re-open if that is the case, sorry for pinging reviews too early.

github-actions · 2025-11-25T17:04:05Z

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.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,661	-	8,939	-3%
GET With Sentry	1,735	20%	1,799	-4%
GET With Sentry (error only)	6,106	70%	6,135	-0%
POST Baseline	1,174	-	1,217	-4%
POST With Sentry	588	50%	614	-4%
POST With Sentry (error only)	1,036	88%	1,071	-3%
MYSQL Baseline	3,327	-	3,342	-0%
MYSQL With Sentry	456	14%	511	-11%
MYSQL With Sentry (error only)	2,687	81%	2,726	-1%

View base workflow run

This is part of the work done for supporting Next.js on cloudflare workers in #14931, one of the issues is our flusher didn't take cloudflare into account and the events were being cut off due to early shutdowns by the worker environment. We cannot use our core's `flushIfServerless` because it requires explicit `cloudflareWaitUntil` to be passed down to it. Also The symbol we are grabbing here is [specific to opennext](https://github.com/opennextjs/opennextjs-cloudflare/blob/b53a046bd5c30e94a42e36b67747cefbf7785f9a/packages/cloudflare/src/cli/templates/init.ts#L17) and isn't something that is globally available on the worker environment. I had initially created #18330 because I mistook it for a worker environment API thing. So this PR adds that detection to Next.js since it is relevant here and will use it if available, local tests show flushing is done correctly and events aren't being cut off.

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

logaretm added 3 commits November 25, 2025 18:30

feat(core): add cloudflare flushing logic to core util
8e16917

ref: return void
829b2cf

ref: safer typed logic
bc58563

logaretm requested review from AbhiPrasad, chargome and s1gr1d November 25, 2025 16:51

ref: smaller bytes
2146b00

logaretm closed this Nov 25, 2025

logaretm removed request for AbhiPrasad, chargome and s1gr1d November 25, 2025 18:02

logaretm mentioned this pull request Nov 26, 2025
feat(nextjs): Add cloudflare waitUntil detection #18336
Merged

logaretm deleted the awad/cloudflare-core-flush branch December 8, 2025 20:18

Uh oh!

Uh oh!

Conversation

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What I considered

Uh oh!

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actionsBot commented Nov 25, 2025

node-overhead report 🧳

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What I considered

Uh oh!

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actionsBot commented Nov 25, 2025

node-overhead report 🧳

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What I considered

Uh oh!

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actionsBot commented Nov 25, 2025

node-overhead report 🧳

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What I considered

Uh oh!

logaretm commented Nov 25, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actionsBot commented Nov 25, 2025

node-overhead report 🧳

Uh oh!

Reviewers

Assignees

Labels

Projects

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading

logaretm commented Nov 25, 2025•
edited
Loading