[rmcdaniel]

Review tier B: HTTP status and body parity on a single refusal. No storage, locking or auth change.

Stacked on #965 (follow-up to #964). Draft until #965 merges, after which the diff is only this change.

Change

PHP's WorkflowQueryTaskBroker answers QueryTaskQueueFullException with queryFailed(..., 'query_task_queue_full', $message, 429): the query refusal body, and no Retry-After. Native answered a bare 503, so clients that back off on 429 treated a full queue as a server fault.

Native now answers 429 with PHP's body: workflow_id, run_id, target_scope, query_name, result: null, reason and message, plus the existing control-plane envelope.

• Message: PHP's exact wording, "Query task queue [] in namespace [] reached the configured pending limit of ."
• Limit: whichever native bound refused the query, MAX_PENDING (16) or MAX_ENTRIES (64).
• Also covered: the same answer applies when the namespace's open set is full at filing time.
• Unchanged: the cutover's internal refusal.

No SDK change is needed: the reason is already in the control-plane contract's rejection reasons.

Tests

queries_bound_abandoned_requests_reclaim_expired_entries_and_deliver_worker_failure now checks 429, the refusal body and the exact message. All 42 query execution tests pass on SQLite.

🤖 Generated with Claude Code

[rmcdaniel]

Security bounded review of exact head 14eb69dc542d5ddb1fcd7c2b3d14142141647d84: source clear for the 429 parity change.

The merge base is the protected-main commit that merged #965, and the resulting delta is exactly queries.rs plus its execution assertion. No query-cache storage, lock, cutover, authorization, or routing behavior changes.

• The ordinary admission limits now use the existing query-refusal protocol response with HTTP 429, query_task_queue_full, the bound workflow/run/query identity, target_scope=instance, null result, and PHP's exact queue/namespace/limit message.
• The selected limit is 16 when the pending bound is reached, otherwise the 64-entry defensive bound. The post-insert list_open capacity refusal is translated to the same customer response and its uncommitted insert remains inside the transaction, so it rolls back.
• The one-time 3.0.1 cutover still handles a full legacy open set internally and does not gain the customer-facing mapping.
• No Retry-After header path is introduced. The status change therefore matches the recorded SDK survey rather than granting new retry or authority behavior.
• The focused test discriminates the old bare 503 and binds 429, reason, identity fields, null result, nonempty run ID, and exact 16-limit message.

Hosted checks are rerunning on this rebased exact head, so this is source clearance only. Final carry requires the terminal hosted result; any source change needs re-review.

[rmcdaniel]

Security bounded source review of exact head 14eb69dc542d5ddb1fcd7c2b3d14142141647d84: source-clear for the Tier-B 429 parity change.

The refusal remains inside the serialized admission transaction, creates no row on either bound, and now carries the exact workflow/run/query/queue/namespace context through the existing query-refusal envelope. The 16-open path reports 16; the open-set filing refusal is translated only from query_task_queue_full and reports the 64-entry hard bound. Other filing errors still propagate unchanged. No retry header, auth, storage, or SDK behavior is added.

The regression proves 429, reason, exact context/body/message and the active 16 limit; all hosted checks on this head are terminal green. This is a bounded source clearance only: the branch is stacked on #965's merge commit and must be carried onto the eventual 3.0.3 main tip, with a zero-unexpected-diff readback and terminal checks, before merge/release clearance.

[rmcdaniel]

Security carry review at exact c2493e1549c855da686c4e36b1f5634a9bb14436: this is a two-parent merge of the previously source-cleared 14eb69dc542d5ddb1fcd7c2b3d14142141647d84 and current main 0e6fc80a34941098696c53f42289874cf9f98d15. The feature delta remains exactly rust/src/runtime/queries.rs plus rust/tests/execution.rs, and both paths are byte-identical to the cleared head. Source carry is clear; merge clearance remains bounded on the fresh hosted checks, which are still running with no failure currently reported.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

Security final clearance at exact carry head c2493e1549c855da686c4e36b1f5634a9bb14436. The feature paths remain byte-identical to the previously reviewed 429-parity source, the carry is only current main, and all hosted checks are terminal green. Clear to merge for 3.0.3.