Skip to content

Read one fairness batch before the whole claim candidate page - #1092

Merged
rmcdaniel merged 2 commits into
mainfrom
feat/server-1064-first-fairness-batch
Nov 7, 2026
Merged

rmcdaniel merged 2 commits into
mainfrom
feat/server-1064-first-fairness-batch

Conversation

@rmcdaniel

Copy link
Copy Markdown
Member

Implements the source part of #1064 (refs #1064; the issue stays open for published-artifact acceptance). This is the operator-requested split of the first-batch piece out of #1088 (6707046455). The PostgreSQL candidate change (#1069) already merged from #1088. #1066 follows in its own PR.

What changes

A workflow or activity claim used to read the whole 100-row candidate page before trying the first task. It now reads the first 10 candidates (one fairness batch) and tries those first.

  • If fewer than 10 rows come back, that is already the complete candidate set.
  • If 10 rows come back but unsupported workflow types leave fewer than 10 eligible, the first batch can't be decided from the short read. The claim reads the full page before trying anything, so batch boundaries match the old behavior.
  • If none of the first batch can be claimed, the claim reads the full page once. It reapplies fairness ordering over the whole page, then skips IDs it already tried, so later batches keep their original boundaries.
  • The two sampled instants (lease_at, ready_at) are captured once and reused for both reads.
  • The has-ready-work check uses the 10-row query. It only needs one row.

The SQL for each backend is the existing candidate query with only the LIMIT parameterized. This covers SQLite, PostgreSQL's per-status ranges, and MySQL's per-status UNION ALL, where both ranges and the outer limit take the batch limit. Claim authority, receipts, typed errors and persistence budgets are unchanged.

Tests

  • tests/execution/task_fairness.rs: two HTTP fairness regressions through the real API.
  • poll_transaction_tests.rs: qualify_first_candidate_batch, shared across SQLite, PostgreSQL and MySQL, checks statement counts:
    • claimable first batch: one 10-row read and no full read;
    • ten unsupported workflow types ahead of a supported task: one 10-row read plus one full read.
  • PostgreSQL and MySQL candidate tests check plans and row order for both limits, fresh and after ANALYZE.
  • The MySQL template test checks positional binding uniqueness for both limits.

Provenance

The code is the preserved preparation e9872912 (from main dc2a9d10, recorded on #1064 at comment). It was rebased without conflict onto current main 1c34f3b7; main's changes since dc2a9d10 touch only the qualification runner and a PHP test. No earlier #1088 result carries over to this head. No external reference patch was applied.

Local result (lab4, CI's pinned Rust image rust@sha256:ba81bc3e…, 2 CPUs)

  • cargo test --locked --offline --lib runtime::: 413 passed, 0 failed (79 ignored backend-only tests run in CI).
  • cargo test --locked --offline --test execution task_fairness: 3 passed, including both new regressions.

The PostgreSQL/MySQL/MariaDB qualifications run in the normal PR checks.

🤖 Generated with Claude Code

@sonarqubecloud

sonarqubecloud Bot commented Nov 7, 2026

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

Current-head CI is terminal at 463d0c8d2c8d1ba5bb9b49ca159b37638c63b14f (tree 4d68a84b, base main 1c34f3b7): 62 pass / 1 intended skip / 0 failure, including the PostgreSQL/MySQL/MariaDB native qualifications and the 48-job Shared fixtures run. The #325 qualifier freeze that held this PR has ended; that stage is terminal. Requesting Security's exact-head source review. Server will mark the PR ready and enter the normal merge queue after that review. #1093 (#1066) is the separate follow-on PR.

@rmcdaniel

Copy link
Copy Markdown
Member Author

SOURCE PASS for Server PR #1092 at exact head 463d0c8d2c8d1ba5bb9b49ca159b37638c63b14f, tree 4d68a84b266bb856f7b10e8db88314ebcd5f2313, base 1c34f3b7de22d27c7c7a28c6b245680d7f7fbffd. This disposition is limited to the nine changed Source/test paths and does not authorize merge, publication, or runtime effect.

Independent review found no blocking Source issue. The complete binary delta is SHA-256 e5db6d69c966e676a13e09ccef7f89add8284f1e537b709cde1694367be2fc14 (+237/-54). The final nine changed paths are byte-identical to the preserved e98729126320c7c099d9f558c6f8d7790645c806 preparation; the two-commit rebased head retains its complete test coverage.

Verified behavior and bounds:

  • lease_at and ready_at are sampled once and reused by the short and full reads in the same serialized claim transaction.
  • A raw page shorter than 10 is complete. A raw page of 10 whose supported workflow types produce an incomplete eligible batch reads the full 100-row page before trying any candidate.
  • When every first-batch candidate is unclaimable, the full page is read once, fairness ordering is recomputed over that complete page, and only then are already-tried IDs removed. This preserves later batch boundaries and prevents the first unclaimable batch from hiding later work.
  • SQLite, PostgreSQL, and MySQL use the existing fully filtered candidate query with compile-time literal limits only. PostgreSQL and MySQL bind both status ranges consistently; MySQL retains 12 unique positional values across both ranges. Per-status and outer limits are all 10 for the first read and 100 for the full read.
  • Claim authority, receipts, type/capability checks, locks, lease mutation, and error behavior remain in the existing path. The readiness probe uses the 10-row query only as an existence check.

The actual exact-head checks are terminal: 62 SUCCESS, one intentional prepared-local/cancellation SKIPPED, zero failures or pending checks. This includes the SQLite, PostgreSQL 17, MySQL 8.0, MariaDB 10.11, existing-PHP matrices, causal fairness tests, plan/order controls, CodeQL, Sonar, and public-boundary checks.

@rmcdaniel
rmcdaniel marked this pull request as ready for review November 7, 2026 20:25
@rmcdaniel
rmcdaniel added this pull request to the merge queue Nov 7, 2026
@rmcdaniel

Copy link
Copy Markdown
Member Author

Security's exact-head SOURCE PASS (above) matches the current head 463d0c8d, and all checks are terminal: 62 success, 1 intended skip. I marked the PR ready and entered the normal merge queue once, at 2026-11-07T20:25:14Z (position 1, QUEUED). Server owns the queue result, the actual-main checks and branch cleanup. The #325 runner successor is the next Source train after this merges.

Merged via the queue into main with commit 2c7ea79 Nov 7, 2026
63 checks passed
@rmcdaniel
rmcdaniel deleted the feat/server-1064-first-fairness-batch branch November 7, 2026 21:01
@rmcdaniel

Copy link
Copy Markdown
Member Author

Main acceptance and cleanup are complete. Merge 2c7ea791 has tree 4d68a84b (equal to the reviewed head tree) and parents [1c34f3b7, 463d0c8d]. All main workflows passed: SonarQube 42412694253, Public Boundary 42412694264, Shared fixtures 42412694299, PHPUnit Feature 42412694345 and CodeQL 42412693382. Commit checks: 71 success, 8 intended skips, 0 failures. The topic branch was deleted with an exact-head lease on 463d0c8d; REST reports branch not found, and the local branch was removed after an ancestry check.

@rmcdaniel

Copy link
Copy Markdown
Member Author

ACTUAL-MAIN SOURCE PASS — protected main 2c7ea791fce2549559507e5a235070f27292ee0c, tree 4d68a84b266bb856f7b10e8db88314ebcd5f2313, ordered parents [1c34f3b7de22d27c7c7a28c6b245680d7f7fbffd, 463d0c8d2c8d1ba5bb9b49ca159b37638c63b14f], valid GitHub signature.

The reviewed PR tree is preserved exactly. All current-main workflows are terminal: CodeQL, SonarQube, Public Boundary, Shared Server fixtures, and PHPUnit Feature succeed; the merge-queue Sonar follow-up is intentionally skipped. This carries the finite Source review to actual main only. Published-artifact/performance acceptance and owner topic cleanup remain separate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant