[mariojgt]

What changed

On Lovable's current template, blocking works but the firewall log stays empty. That template builds with Nitro for Cloudflare Workers.

Why the reports were lost: Cloudflare calls the Worker with (request, env, ctx), but Nitro calls the app's fetch with the request alone. It puts the host's waitUntil on the request itself (request.waitUntil, plus request.runtime.cloudflare.context). The guard's fetch() only looked for waitUntil in an argument beside the request. It found none, so it returned the 403 with the report still in flight, and Cloudflare cut the report off when the response went out.

src/protect/runtime.js

• hostWaitUntil finds waitUntil beside the request, on the request, or on request.runtime.cloudflare.context. The background rules check from [NO-TICKET] Re-check rules in the background every 30 seconds #443 uses it too, so those checks are no longer cut off on these hosts either.
• No waitUntil at all: fetch() now delivers within the request, as fetchGuard() has since [NO-TICKET] Deliver a blocked attack's detection before returning the 403 (reliable firewall logs on a frozen-between-requests runtime) #432. A block waits up to 2 seconds for its report to land before the 403 goes out (bounded, fail-open). A detect-only report goes out on a later request once it is 10 seconds old. Both paths share one routine (deliverInRequest).

AGENT-INSTALL.md: a short "Delivery" note in "Runtime guard reporting" says when reports are sent, and the background-check sentence names where waitUntil is found.

How it was verified

• Real Lovable build: I rebuilt a Lovable app's Worker (Nitro, cloudflare-module preset) with this runtime and called it as Cloudflare does, fetch(request, env, ctx), against a stubbed Patchstack API. The attack got 403, the report was handed to waitUntil (1 item), and it reached POST …/detections/<uuid>. Before this change nothing was handed over.
• New tests in tests/protect/rules-reader.test.ts, which all fail on the previous runtime:
  • a Nitro-style request carrying waitUntil;
  • one carrying runtime.cloudflare.context;
  • a host with no waitUntil, behind a deliberately slow detections endpoint, where the report must be delivered before the 403 is returned.
• Gates: npm run typecheck, npm run build, full npm test (4625 passed), capabilities:check are green. An earlier full run had 4 timing tests time out under load. Each passes alone, and the one touching setup takes the same ~1.2s on this branch and on main.

Rollout

• Apps pick it up when they update @patchstack/connect and republish. No setup re-run is needed.
• AGENT-INSTALL.md changes, so the hostile field test is owed after the release that carries this, plus lovable for doc accuracy.

🤖 Generated with Claude Code

[coderbuds]

🎯 Elite quality (95%) — Extracts a shared hostWaitUntil helper so Nitro-style request-attached waitUntil works for reports and rule refresh.

📦 Medium

_{See how your team is trending →}

[mariojgt]

/review