worker: respect Browser Run's launch cadence and daily budget - #55
Merged
Merged
Conversation
With one theme a visitor rarely rendered two PDFs in quick succession; with twenty-one they do, and Browser Run refuses a second new browser within about a minute of the first, so the second uncached PDF returned 502 in half a second. Keep the browser alive for ten minutes after a render (disconnect instead of close), reattach to an idle session on the next render, and only launch when none is free, retrying twice with a short backoff when the launch is refused. Log the account's Browser Run limits alongside a render failure so the cause is visible without reproducing it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Aswincloud-Bot
approved these changes
Sep 16, 2026
Aswincloud-Bot
left a comment
Aswincloud-Bot
left a comment
There was a problem hiding this comment.
Auto-approved: @Aswinmcw is a member of @Aswincloud/admins.
Contributor
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
resume | da4d508 | Commit Preview URL Branch Preview URL |
Sep 16 2026, 09:08 AM |
A session released by a render that just finished is not listed as idle for a moment, so a request that arrived meanwhile burned its launch retries and failed even though a browser was about to be free. Loop for up to 15s: reattach if a session is idle, launch only while the account's per-minute launch budget allows, otherwise wait and look again. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…daily budget is spent Keeping browsers alive was the wrong trade on Workers Free: an idle session consumes the 10-minute daily browser-time budget as fast as a working one, and two kept-alive sessions burned the whole day's allowance. Revert to one fresh browser per render, closed in finally. The failure a visitor actually hits is the launch cadence (one new browser every 20 s): the second uncached PDF used to fail in half a second. Now launchBrowser consults puppeteer.limits() and waits up to 25 s for the next slot. A refusal while the launch budget says yes is the daily cap, which is reported as 503 with Retry-After and a human-readable message instead of a bare 502. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Aswinmcw
changed the title
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem
After #54 and the twenty theme PRs, rendering two uncached theme PDFs back to back on production fails: the first renders in 5–10 s, the second returns
502 Failed to render PDF.in ~0.5 s.This account is on Workers Free, where Browser Run allows one new browser every 20 seconds, 3 concurrent, and 10 minutes of browser time per UTC day. With one theme nobody rendered twice in 20 s; with twenty-one a visitor clicking through
/themesdoes it immediately.Fix
launchBrowser()consultspuppeteer.limits()and, when no launch is allowed yet, waits for the next slot (up to 25 s) instead of failing.finally. (An earlier revision of this PR kept sessions alive for reuse; that burns the 10-minute daily budget while idle — two kept-alive sessions used the whole day's allowance during testing — so it was reverted.)Retry-After: 3600and a readable message, instead of a bare 502. Limits are logged next to every render failure.Test plan
tsc --noEmitRetry-After(verified today, since testing spent the budget).🤖 Generated with Claude Code