v10.0.11

DKG v10.0.11

A focused stability release on two paths a busy node exercises constantly. One external /api/query read could amplify into a planner-stalling query that starved every other subsystem: a caller that had already constrained GRAPH ?g to a handful of verified partitions was rewritten with a second VALUES ?g carrying the entire allow-list, expanding a 3 KB query to roughly 24 KB and occupying the store for minutes, cascading into queue-wait timeouts across promotion, gossip validation, SWM catch-up, and durable sync. External reads now run on the store scheduler's background lane, a disconnected caller's store work is cancelled instead of orphaned, and the redundant graph rewrite is elided. Separately, the dkg integration CLI is brought back into line with the registry's published JSON Schema, which its parser had drifted stricter than — so no manual entry was readable at all, in either the CLI or the node dashboard's integrations sidebar. The dashboard database stays at 31 — no migration. No smart-contract changes — no deployment required (no Solidity source, ABI, or deployment-registry changes since 10.0.10).

npm: @origintrail-official/dkg@10.0.11 — dist-tags latest, mainnet

Upgrading from 10.0.10

Change	Impact	Action
POST /api/query is admitted on the store scheduler's background lane	external reads no longer compete for the capacity normal node work depends on. Under stock tuning the background lane admits one concurrent store operation where the normal lane admitted two, and API reads now queue behind background node work, so concurrent callers can see higher latency	none for correctness. Set DKG_API_QUERY_PRIORITY=normal before starting the daemon to restore 10.0.10 admission. The daemon logs the effective lane once at boot; an invalid value warns and falls back to background
A query shed before execution returns 503, previously 500	the body carries code: "STORE_SCHEDULER_BUSY", reason, priority and retryable: true, with a Retry-After: 1 header. Shedding is governed by DKG_STORE_BACKGROUND_QUEUE_LIMIT and DKG_STORE_QUEUE_WAIT_TIMEOUT_MS. Read paths only; write routes are untouched	treat 503 on /api/query as retryable and honour Retry-After. Clients keying on exactly 500 for overload must be updated
A disconnected /api/query caller now cancels its store work	the queued or in-flight SPARQL request is aborted instead of running to completion. The operation is recorded as cancelled, not error	none. A client that times out and retries no longer leaves orphan store work behind it
Dashboard operation health excludes cancelled and in-progress rows	successRate is now success / (success + error) instead of success / total, in the summary, the time series and the per-operation breakdown. A new cancelled status appears in operation rows and in the Operations page filter	none. Historical rates shift upward where in-progress rows were previously counted as non-successes. No schema migration — the dashboard database stays at 31
dkg integration now parses every entry the published registry schema permits	entries the CLI wrongly reported as unreadable appear in dkg integration list/info and in the dashboard integrations sidebar. dkg integration install <manual-entry> prints the entry's docsUrl and exits 0, where 10.0.10 exited 1	none for the public registry; list output and its --json shape are unchanged. An operator pointing DKG_REGISTRY_RAW_BASE at a private or staging registry must bring entries into line with the published schema: manual carries docsUrl (not steps), and docker/npmGlobal payloads require version

Added

• dkg integration search and dkg integration installed, plus automated npm-global service installs (#1988): search [keyword] filters the registry case-insensitively over slug, name, description and category; installed reports what is present on this machine, derived from the real install targets (npm ls -g, and the MCP client configs dkg mcp setup writes) rather than from a ledger that could claim installs that never happened — an entry whose kind cannot be probed reports unknown with its own reason, never "not installed". dkg integration install now performs service entries with runtime: npm-global under the same npm provenance gate as cli entries; docker and binary runtimes still exit cleanly pointing at the integration's own instructions.

Fixed

• One scoped API query no longer stalls the store for every other subsystem (#1991, #1994): a caller that had already constrained GRAPH ?g to a handful of verified Verifiable Memory partitions was rewritten with a second VALUES ?g carrying the entire allow-list, expanding the query roughly eightfold and occupying the store until the client deadline, cascading into queue-wait timeouts across promotion, gossip validation, SWM catch-up and durable sync. The redundant injection is now skipped when a simple top-level static VALUES names only graphs already inside the allow-list. Scoping stays fail-closed: tuple VALUES, variables, literals, UNDEF, nested groups, unresolvable prefixes, or any out-of-scope graph all keep the previous intersection rewrite, and result sets are unchanged because a subset intersected with the allow-list is that same subset.
• A disconnected caller no longer leaves orphan store work, and shutdown drains what is in flight (#1991, #1994): cancellation, admission priority and a store-work label now travel from the daemon route through the agent and the query engine to the SPARQL adapter, so an HTTP timeout or client disconnect aborts the queued or in-flight request instead of letting it hold a scheduler slot. SparqlHttpStore.close() was a no-op — it now aborts and awaits its outstanding work, which is why slow-query completions could previously surface after the daemon had logged Stopped.
• Registry entries the CLI declared unreadable are readable again (#1988): the integration validator was stricter than the registry's published JSON Schema in three places — manual required a steps array the schema forbids, mcp required the schema-optional args, and service rejected the schema's binary runtime — so no manual entry could ever parse. The same parser backs both dkg integration and the dashboard integrations sidebar, so both dropped them. Installing a manual entry is now the documented success path: print its docsUrl, one-liner and security declaration, and exit 0. info renders manual entries and the service binary runtime, which previously printed nothing. The invariant is now recorded in code — this validator must never be stricter than the published schema, only more lenient, so an older CLI can still read a newer registry.

Changed

• POST /api/query is admitted as background store work labelled api.query (#1991, #1994): external reads are untrusted and potentially planner-heavy, so they no longer compete for the slots normal node work depends on. DKG_API_QUERY_PRIORITY=normal reverts the lane, and pre-dispatch shedding returns 503 with Retry-After: 1 on the read paths only. Slow-query telemetry now classifies through the canonical SPARQL classifier, so a query behind a PREFIX/BASE prologue or a comment is attributed as source=api.query operation=select instead of source=unknown operation=unknown.
• A cancelled operation is its own dashboard state, not a failure (#1991, #1994): a request the caller abandoned is recorded as cancelled on both the operation and its active phases, the Operations page gains a cancelled status filter and colour, and operation health becomes success / (success + error) so neither cancelled nor in-progress work counts against the success rate. Additive at the SQL level — the dashboard schema stays at 31, so no migration and no rollback risk.
• Release version set: all workspace packages move together to 10.0.11.

Deployment

• No contract changes in this release. No Solidity source, ABI, or mainnet/testnet deployment-registry files changed since 10.0.10; nodes can upgrade through the normal npm release path.

Known issues

• The Node runtime floor introduced in 10.0.10 is unchanged and still applies: @origintrail-official/dkg and @origintrail-official/dkg-agent require a runtime where node:sqlite is available unflagged (Node >= 22.13, or >= 23.4 on the 23.x line), engines stays advisory under npm and pnpm, and blue-green auto-update does not prove the new slot boots. Check node --version before upgrading.

Full changelog: v10.0.10...v10.0.11