Revision 1 — the current text. The evidence on this page is this revision’s own — it has not been carried forward from, or to, any other revision.
Covers the D1-specific per-invocation request cap being hit by an N+1 query pattern or by combining many D1 calls with other subrequests in one invocation. Does not cover the general Workers subrequest limit for fetch()-only Workers with no D1 involved (see Workers platform limits), and does not cover D1's separate CPU-time or memory-limit resets, which return different error text entirely.
Unverifiedno reproductions yetWhy this confidence?8 steps, exactly as this revision published them.
A single Worker invocation that makes many separate calls to D1 fails partway through with this D1-specific error, distinct from D1's CPU-time or memory-limit reset messages.
What happens next
Look for an N+1 pattern: a loop that runs one env.DB.prepare(...).run() (or .all()/.first()) per row instead of one query covering all the rows, or one db.batch() call.
grep -n "env.DB.prepare\|\.first(\|\.all(\|\.run(" src/**/*.tsExpected result
A `.prepare(...)` call sitting inside a `for` loop or `.map()`/`.forEach()` over a list of rows.What happens next
Collapse the per-row queries into a single query with WHERE id IN (...), or, when each row needs a different statement (e.g. different values on an UPDATE), combine them into one db.batch([...]) call. Either way this turns N D1 requests into one.
Changes system or service state. Review before running.
Changes how the data is fetched (one query instead of N), not what is returned. For writes, batching via db.batch() still executes every statement — it just sends them in one round trip.
// Before: one query per row
// for (const id of ids) { await env.DB.prepare("SELECT * FROM items WHERE id = ?").bind(id).first(); }
// After: one query for all rows
const placeholders = ids.map(() => "?").join(",");
const { results } = await env.DB.prepare(
`SELECT * FROM items WHERE id IN (${placeholders})`
).bind(...ids).all();What happens next
D1 calls count against the same per-invocation subrequest budget as fetch(), KV, and R2 calls. If this invocation also makes several other bound-service calls alongside its D1 queries, the combined total — not D1 alone — may be what's tipping it over.
grep -n "env\.\(DB\|KV\|R2\|BUCKET\)\.\|fetch(" src/**/*.tsExpected result
Several distinct bound-service calls (D1, KV, R2, fetch) all inside the same handler.What happens next
Repeat the request that previously failed, using the same (or larger) row count, and confirm it completes without the D1_ERROR.
curl -s https://your-worker.example.workers.dev/bulk-endpointExpected result
A normal 200 response covering the full data set, with no D1_ERROR in wrangler tail.What happens next
First prefer reducing the total number of calls (the N+1 fix above, or caching repeated lookups). If the workload genuinely needs a high subrequest count, Workers Paid plans can raise the configured limits.subrequests above the 10,000 default, up to 10,000,000.
Changes system or service state. Review before running.
Raises the maximum number of subrequests this Worker may make per invocation. It does not reduce or change any query results — it only allows more calls before the runtime cuts the invocation off. Available on the Workers Paid plan.
{
"limits": {
"subrequests": 50000
}
}What happens next
If the invocation genuinely makes few D1 calls and this error still appears, check for an actual infinite loop or unbounded recursion calling the same query repeatedly, rather than a data-volume problem.
The invocation now makes far fewer D1 requests (or has room for the ones it needs), and the error no longer occurs.
What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.
This counts only what was recorded against revision 1 itself. Nothing reported against another revision is included here — see the revision history for why.