fix(zero-cache): cap AST depth to prevent unauthenticated CPU DoS

[Karavil]

Summary

An unauthenticated WebSocket client can open a connection to zero-cache and send an initConnection (or changeDesiredQueries) message whose desiredQueriesPatch[*].ast contains a deeply-nested condition tree:

let cond = { type: 'simple', op: '=', ... };
for (let i = 0; i < N; i++) cond = { type: 'and', conditions: [cond] };

There are two recursion surfaces that overflow under such input:

1. Valita schema parsing of astSchema / conditionSchema in packages/zero-protocol/src/ast.ts. The schema is structurally recursive via v.lazy(...), so every nesting level burns one JS frame. Overflow lands around depth ~900 (RangeError at parse, ~150 ms).
2. Downstream AST visitors in transformQuery / transformQueryInternal / transformCondition (packages/zero-cache/src/auth/read-authorizer.ts), simplifyCondition (packages/zql/src/query/expression.ts), bindStaticParameters (packages/zql/src/builder/builder.ts), and hashOfAST / normalizeAST. These overflow slightly earlier (~800) and burn ~6.5 seconds of CPU at the sweet spot because the AND/OR rewrites in simplifyCondition re-walk the tree.

The error is caught and the connection closed, so the worker process does not crash — but per-request CPU at the depth-~800 sweet spot is enormous, and no authentication is required. A trickle of crafted requests would saturate sync workers.

Measured against a production zero-cache (protocol v50) before this patch:

Depth	Server result
≤ 700	Parses + transforms successfully (CPU cost grows with depth)
800	Internal: Maximum call stack size exceeded after 6.5 seconds of CPU
900+	InvalidMessage: RangeError: Maximum call stack size exceeded at parse, ~150 ms

Found during a SOC 2 audit of an opaque-token deployment.

Fix shape

The depth check is folded into the schema layer: a new depthBoundedAstSchema (chain-wrapped variant of astSchema) is substituted at the wire-entry points that accept client-supplied ASTs. No envelope-specific guard or call-site assert(...) is added — too-deep inputs fail through the same v.parse error path as any other malformed message.

1. New constant MAX_AST_DEPTH = 50 in packages/zero-protocol/src/ast.ts.
2. New assertAstDepth(ast, max) — an iterative walker (explicit worklist) over the mutually-recursive Condition ↔ AST surface (handles and / or conditions, correlatedSubquery → ast → where → ..., and AST.related[].subquery). Throws if any branch exceeds max. Iterative because the guard cannot itself stack-overflow the path it is protecting.
3. New depthBoundedAstSchema export — v.unknown().chain(value => { try { assertAstDepth(value); } catch (e) { return v.err(...); } return astSchema.try(value); }).
4. Wire-entry sites now reference depthBoundedAstSchema instead of astSchema:
   • packages/zero-protocol/src/queries-patch.ts:upPutOpSchema.ast (every desiredQueriesPatch[].ast from a client)
   • packages/zero-protocol/src/inspect-up.ts:inspectAnalyzeQueryUpSchema.ast and .value (the inspector's analyze-query op)

upstreamSchema is untouched. connection.ts is untouched. The check rides on top of the existing schema mechanism rather than a parallel guard.

The depth limit is 50. Headroom argument: the deepest realistic permission-rule plus user-where combination is ~6 levels; 50 is roughly 8×. Easy to raise if any consumer reports a real workload that needs more — it's a single constant.

Wire compatibility & legacy data

Server-internal usages of astSchema (CVR row loading in cvr-store.ts, inspector downstream responses, etc.) are deliberately not switched. Existing deployments may have CVR-stored ASTs deeper than 50 from before the cap; those should still load. Callers that want a depth bound at a server-side site can opt in by switching their reference to depthBoundedAstSchema.

protocol-version.test.ts hashes JSON.stringify(schema). Switching upPutOpSchema.ast and the inspect-up AST fields to the chain-wrapped variant changes the schema object's serialized shape, so the hash moves even though the wire grammar is unchanged. The hash is bumped accordingly.

To prove the wire grammar is actually preserved (so reviewers don't have to take that on faith), this PR adds packages/zero-protocol/src/upstream-schema.test.ts — a new regression suite that:

• Round-trips a minimal representative payload through v.parse(..., upstreamSchema) for every upstream message type (initConnection, ping, deleteClients, changeDesiredQueries, pull, updateAuth, push, closeConnection, inspect × 4 ops, ackMutationResponses) and asserts the parsed value equals the input.
• Asserts that obviously-malformed payloads (wrong tag, missing required fields, wrong types) are rejected.
• Asserts that initConnection and changeDesiredQueries with a depth-1000 AST in desiredQueriesPatch are rejected through the standard v.parse error path.

protocol-version.test.ts's comment now points at upstream-schema.test.ts as the actual wire-grammar contract; bumping the hash without bumping PROTOCOL_VERSION is safe iff the wire-grammar suite still passes.

What was intentionally not done

• Did not rewrite transformQueryInternal, transformCondition, simplifyCondition, or bindStaticParameters to be iterative. The wire layer caps depth at 50; the downstream visitors will never see deeper input. Doing the rewrite would touch subtle semantics (AND/OR flattening, NOT/EXISTS, static-parameter binding) for no security benefit.
• Did not add a per-AST byte-size cap. The existing websocketMaxPayloadBytes (10 MB default) already bounds total request size.

Tests

In packages/zero-protocol/src/ast-depth.test.ts (new):

• AND chains, EXISTS chains, related[] chains at the limit, just below, and well above
• Custom limit override behavior
• Malformed input tolerance (depth check doesn't trip on missing fields)
• Wall-clock budget at depth 1000

In packages/zero-protocol/src/upstream-schema.test.ts (new):

• Wire-grammar round-trip for every upstream message type
• Negative cases for the most common malformed shapes
• Depth-guard rejection for initConnection and changeDesiredQueries

Test results

• packages/zero-protocol: 85 / 85 passing
• packages/zero-cache/no-pg: 1275 / 1275 passing
• packages/zql: 1277 / 1277 passing
• Type check: clean
• Lint: 0 errors

Test plan

• Wire-grammar suite covers every upstream message type and proves wire-compatibility under this refactor
• Depth-guard suite covers AND, EXISTS, and related[] recursion paths
• Existing zero-protocol, zero-cache/no-pg, zql test suites pass

[vercel]

@Karavil is attempting to deploy a commit to the Rocicorp Team on Vercel.

A member of the Team first needs to authorize it.