Skip to content

chore: sync main into testnet-canary after 10.0.11 - #2001

Merged
Jurij89 merged 3 commits into
testnet-canaryfrom
main
Jul 30, 2026
Merged

chore: sync main into testnet-canary after 10.0.11#2001
Jurij89 merged 3 commits into
testnet-canaryfrom
main

Conversation

@Jurij89

@Jurij89 Jurij89 commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Summary

Re-equalizes testnet-canary with main after the 10.0.11 release. Fast-forward only — testnet-canary is fully contained in main (0 commits ahead, merge-base == canary tip), so there is nothing to resolve.

main is 3 commits ahead: 22 files, +59 / −21.

What canary is missing

Commit Content
5b149f6d1 Merge #1999 — the testnet-canarymain promotion (the merge commit itself; its content originated on canary)
47be53243 chore(release): bump version set to 10.0.11
2ca1f46dd Merge #2000 — the release-prep PR

The effective diff is only the version bump and the CHANGELOG entry — verified: filtering the changed-file list for anything that is not a package.json or CHANGELOG.md returns nothing.

Canary currently declares 10.0.10; this brings it to 10.0.11 along with the ## [10.0.11] CHANGELOG section and its ### Upgrading from 10.0.10 matrix.

Nothing stranded this release

Unlike the 10.0.10 cycle — where two fixes were pushed to the frozen release/10.0.10 branch and had to be recovered by the sync — every code change in 10.0.11 landed on testnet-canary first (#1991, #1994, #1988). git rev-list --count origin/main..origin/release/10.0.11 is 0, so the release branch holds nothing that is not already on main.

Risk

Low. Version-only plus documentation. pnpm-lock.yaml is untouched, so pnpm install --frozen-lockfile stays valid. Every commit here is already on main and shipped as 10.0.11 to latest and mainnet.

Note on CI

ci.yml now includes testnet-canary in both the push and pull_request branch filters (#1992), so unlike the 10.0.10 cycle this PR does trigger the full lane.

Merge

Prefer a merge commit over squash, so canary keeps the same per-PR history main has — the CHANGELOG convention depends on recovering PR numbers from the merge history.

🤖 Generated with Claude Code

Jurij89 and others added 3 commits July 30, 2026 08:52
release: promote testnet-canary to main for 10.0.11
Move the root package and all 20 packages/* workspaces to 10.0.11 in
lockstep, per the single-version release set rule in RELEASE_PROCESS.md
§3, and add the 10.0.11 CHANGELOG entry.

Version-only bump: pnpm-lock.yaml records third-party versions only and
is untouched, so `pnpm install --frozen-lockfile` stays valid.
`pnpm release:verify-versions --version 10.0.11` passes (21/21). The
engines.node ranges added in 10.0.10 on packages/cli and packages/agent
are preserved unchanged.

CHANGELOG carries an `### Upgrading from 10.0.10` matrix, required by §10
because this release changes the default admission behaviour and error
contract of a public HTTP API. Verified in the shipped code:
- POST /api/query now defaults to the background store lane
  (api-query-priority.ts:8,12), reversible via DKG_API_QUERY_PRIORITY
  (lifecycle.ts:1175, README.md:60).
- Under stock tuning that lowers API-read concurrency from 2 to 1:
  MAX_CONCURRENT=4 less ACK=1 and HEALTH=1 gives totalLimit=2,
  normalFloor=1, backgroundLimit=max(1, 2-1)=1
  (store-priority-scheduler.ts:97-100,177-181).
- A shed query now answers 503 + Retry-After: 1 where it previously fell
  through to a generic 500.

No Solidity source, ABI, or deployment-registry changes since v10.0.10,
so this release requires no contract deployment. Dashboard SQLite stays
at SCHEMA_VERSION 31 — no migration, no rollback question.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chore(release): bump version set to 10.0.11
@Jurij89
Jurij89 merged commit 12ed10a into testnet-canary Jul 30, 2026
88 of 89 checks passed

@otReviewAgent otReviewAgent left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Agent completed this review and found no issues.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants