Fix unbounded memory growth in Conditional middleware

[zaucker]

Problem

Any HTTP server with a Cro::HTTP::Middleware::Conditional in its pipeline leaks memory: RSS grows linearly and without bound as requests are served. This affects, among others, Cro::APIToken-based authentication (its middleware does Cro::HTTP::Middleware::Conditional) and Cro's own auth middleware — i.e. every authenticated request leaks.

Root cause

Conditional and RequestResponse are built the same way: a Request and a Response transform that share a per-connection SkipPipelineState holding a Supplier $.early-responses. The Response transform taps that Supplier with whenever.

RequestResponse's Response completes the Supplier when its pipeline ends:

whenever wrap-response-logging(...) -> $response {
    emit $response;
    LAST $connection-state.early-responses.done;   # <-- completes the Supplier
}

Conditional's Response never did. The early-responses Supplier is therefore never completed, so the subscription (and the connection-scoped state reachable from it) is retained — leaking per request.

Fix

One line — mirror RequestResponse and .done the Supplier when the pipeline ends:

whenever $pipeline -> $response {
    emit $response;
    LAST $connection-state.early-responses.done;
}

Reproduction & verification

Minimal server with a no-op Conditional middleware, hammered with trivial GET requests:

	before	after
no-op Conditional middleware	RSS climbs linearly, unbounded (~80 KB/req)	plateaus
no-op RequestResponse middleware (control)	plateaus	plateaus
no middleware (control)	plateaus	plateaus

Verified end-to-end in a real app (Cro::APIToken auth): a /api/v1 endpoint that previously grew ~0.27 MB/request now plateaus.

Tests

All existing tests pass against the patched source: t/http-middleware (24), t/http-router (439), t/router-auth, t/http-auth-basic, t/http-auth-webtoken-bearer, t/http-session-inmemory.

I'm happy to add a regression test if you'd like, though a memory-growth assertion is inevitably timing/threshold-based — guidance welcome on the form you'd prefer.

[zaucker]

Worth flagging the blast radius: this isn't limited to apps that explicitly write a Conditional middleware. The router itself wraps every before {} / after {} route block in a Conditional (BeforeMiddleTransform does Cro::HTTP::Middleware::Conditional, Router.rakumod ~line 1211, wired via add-before($conditional.request) / add-after($conditional.response)). So any route { before {...}; ... } — a very common pattern — leaks on every request.

Direct demo, a no-op before { Nil } block, 4000 trivial GETs:

• unpatched: RSS 338 → 707 MB, linear and unbounded
• patched: RSS 280 → 361 MB, plateaus

Same one-line fix resolves it.

[librasteve]

Thanks for the PR.

This looks good to me. Since it’s quite a deep fix, I’d like to see a second review.

[lizmat]

Great to see this PR! @zaucker could you create a PR for the other fix as well?

[zaucker]

Great to see this PR! @zaucker could you create a PR for the other fix as well?

Which other fix? This one?
croservices/cro-openapi-routes-from-definition#15

[zaucker]

BTW: as disclosure, I got a little help by my friend Claude on tracking that down. After an initial rather wild guess about Garbage Collection, it finally found the real culprit and I learned about systematically tracking such a problem down.

The two graphs show the problem we just fixed:

Before/after

Overnight test with memory usage sampling every 15min.

We finally could get rid of our nightly restart of Agrammon. Would have been a real road blocker on a busy web service.

[librasteve]

Thanks for explaining the background. It is very helpful to see your experience with Cro!

I have pulled your PR and tested with Air and raku.org on moar-2026.05 - all functional tests are good.

Looking at croservices/cro-openapi-routes-from-definition#15 I would say we can handle as two parallel PRs ... please note my comment over there.

I just want to spelunk the code to eyeball what .done does.

OK - I am happy with the change. Will merge now and do a point release of cro-http shortly.

(We can do a point release of cro-services on the other PR when that is accepted)

[zaucker]

Looking at croservices/cro-openapi-routes-from-definition#15 I would say we can handle as two parallel PRs ... please note my comment over there.

See my answer there :-)

I just want to spelunk the code to eyeball what .done does.

OK - I am happy with the change. Will merge now and do a point release of cro-http shortly.

Cool, thanks for the fast handling, makes my life easier without a locally patched module.

(We can do a point release of cro-services on the other PR when that is accepted)

Sounds good.