People Chain now counts a staking duration only up to the last confirmation
of the stake plus MaxDataAge (fourteen days), so a stopped noter cannot leave
scores climbing on unchecked data. The bot submitted only on change, which
under that rule would freeze every account whose stake stays put.
confirm.js decides when unchanged stake is sent again: not while a
submission is pending (each one restarts the dispute window), not on
half-read data, and only once the last confirmation is CONFIRM_EVERY_BLOCKS
old (default three days). On a runtime without stakingScore.lastConfirmed
the bot behaves as before.
The direct-staking query failed silently into zeros, and a zero that lands
clears the account's stake clock on chain. It now reports the failure, and a
failure in either half skips the account for that scan.
Every report waits behind the previous one, and a submission only settled
when it reached a block. One the pool dropped, rejected or replaced never
settled, so every report queued after it waited forever. The watchdog meant
to catch a silent bot was armed only after the first scan returned, so when
that first scan was the one that hung there was no watchdog at all: the
production container logged its last line one minute after starting on
2026-10-13 and stayed up, silent, for more than a day.
- submit.js: a submission settles on a terminal status (Dropped, Invalid,
Usurped, FinalityTimeout) or after SUBMIT_TIMEOUT_MS, and releases its
status subscription.
- The watchdog is armed before connecting and counts from the process start
until a scan completes, so a heartbeat left by an earlier process in the
same container does not count for this one.
- The noter's own account is skipped: the chain refuses a noter's report
about themselves, so it failed in every scan.
- Unit tests for both rules, run inside the noter image in CI.
The indexer image now installs from a lockfile, so Dependency Review sees
the @subql packages it builds the indexer from. The mapping imports only
their types, which are erased on emit; the build job now checks that no
@subql import survives in the emitted mapping.
CI ran Node 18 (out of support since 2025-04) while ops/host/subquery-deploy
runs subql codegen/build on the host's Node 20. serialize-javascript 7, which
the build now resolves, needs the global crypto that Node 18 does not have:
the build failed in CI and would have passed on the host.
The indexer image installed @subql/node and the @polkadot -> @pezkuwi aliases
with an unlocked npm install, and the build cache kept the layer from the day
it was first built: the indexers ran @pezkuwi/wasm-crypto 7.5.17/7.5.18, the
build whose ed25519 and secp256k1 are stubs, plus vm2 3.9.19 (the mapping
sandbox, 54 advisories). No lockfile meant Dependabot never saw that tree.
- docker/indexer holds the image's package.json and package-lock.json:
@subql/node 6.4.6 as today, @pezkuwi 16.5.39 / 14.0.26 / 7.5.21, overrides
for vm2 3.12.2, uuid 11 and package-json 7 (got 11). The Dockerfile runs
npm ci on Node 24 (Node 20 is out of support).
- The pruned-state patch stops the build when a pattern matches nothing,
instead of reporting success with the fallback missing.
- CI builds the indexer image and runs the crypto smoke test inside it
through the @polkadot aliases, the way subql-node loads them.
- The root yarn.lock, which the host installs as root on every deploy to run
subql codegen/build, moves the advisory ranges forward with targeted
resolutions and @pezkuwi/braces. Left: elliptic (low, via ethers 5 in
@subql/cli) and sprintf-js (moderate, via jest's argparse 1); neither has
a fixed release.
deploy-vps reached subquery1 as root, through appleboy/ssh-action referenced
by tag, with a key whose comment (mamostehp@MamostePC) made it look like a
person's. It now uses plain ssh with SUBQUERY_DEPLOY_KEY, which the host pins
(authorized_keys restrict,command=) to ops/host/subquery-deploy-ssh: the
commit SHA is its only input. subquery-deploy, run through sudo, does what
the workflow's script did, with three changes:
- It deploys exactly the SHA CI was triggered for, and only a commit on main.
- The host's local edits to tracked files (the indexer manifests) are put
back whether the deploy succeeds or fails. Before, a failed build exited
before `stash pop` and left them stashed.
- Only tracked files are stashed. Stashing untracked ones too (.yarn/, which
yarn install recreates) made every pop fail half-way; that is how 13 stash
entries piled up on the host.
test-deploy.sh covers this against a scratch clone (red with the restore
trap removed); CI runs it with shellcheck. subquery1's host key is pinned.
The indexer endpoints themselves are unchanged. Actions pinned to SHAs; the
secret scanner's own AGPL licence is allowed in dependency review.
@pezkuwi/rpc-provider lists @bizinikiwi/connect as an optional dependency,
so npm installed it, with smoldot, into both images. Both are GPL-3.0, and
the bots never load them: they reach the chains over WsProvider. The images
now install with --omit=optional; with that install both bots load and read
the relay, Asset Hub and People chains.
The lockfiles still list the packages, so Dependency Review, which denies
GPL-3.0, flagged them on the new payout-bot lockfile (the noter's had them
before). It allows exactly those three packages, and the bots job fails if
an image contains @bizinikiwi or smoldot, so the allowance cannot outlive
the reason for it.
Both images ran `npm install` with version ranges and ignored any lockfile,
so what production ran depended on the day the image was built. The live
containers, built on 2026-10-03, run @pezkuwi/wasm-crypto 7.5.17, whose
ed25519, ecdsa and mnemonic generation are stubs that throw. Both bots sign
with sr25519 only, which is why they kept working.
Each bot now has a package.json and package-lock.json (@pezkuwi/api 16.5.37,
keyring, util and util-crypto 14.0.26, wasm-crypto 7.5.20) and its image
installs exactly that with `npm ci`. Node 20 is past its end of life; the
images move to node:24-alpine.
CI gains a `bots` job that builds each image and runs inside it:
scripts/bot-smoke.mjs checks the installed versions against the lockfile and
signs and verifies with sr25519, ed25519 and ecdsa, and the bot itself must
load and stop at the mnemonic it is not given. Against the previous lockfile
the smoke check fails on mnemonic generation, ed25519 and ecdsa.
- Add packageManager field to package.json for corepack
- Add .yarnrc.yml with node-modules linker
- Update all workflows to use corepack enable + yarn --immutable
- Remove yarn cache from actions/setup-node (incompatible with Yarn 4)
SatoshiQaziMuhammed