VersionControl:PRs/pickipedia-mcp/44: Difference between revisions

From PickiPedia: A knowledge base of bluegrass, old time psychedelic jams, and other public domain music
Jump to navigationJump to search
DrivingThatTrain (talk | contribs)
cryptograss/pickipedia-mcp#44, as GitHub has it
 
DrivingThatTrain (talk | contribs)
cryptograss/pickipedia-mcp#44, as GitHub has it
 
Line 16: Line 16:
|deploy=bump PICKIPEDIA_MCP_COMMIT in maybelle-config (hunter/Dockerfile), then redeploy hunter
|deploy=bump PICKIPEDIA_MCP_COMMIT in maybelle-config (hunter/Dockerfile), then redeploy hunter
}}
}}
<pre class="pr-body">re's patch, pushed for her since she can't push from her container. The full write-up is at [User:Re/Pickipedia-mcp: no-change writes are not silently successful (31 Oct 2026)](https://pickipedia.xyz/wiki/User:Re/Pickipedia-mcp:_no-change_writes_are_not_silently_successful_(31_Oct_2026)).
On 31 Oct, three writes to `Cryptograss:Agents/Tasks` each reported success, but the page never changed. The wiki had answered `nochange`. The proposal marking sent the page's existing marked stub back, since the new line normalized to it, so the wiki saw no change and returned `Success` with no `newrevid`. `update-page` turned that into ok-shaped JSON with no revision ID.
Now a `Success` without `newrevid` is reported as a structured failure, category `no_change` (warning level in telemetry). It names the revision the page is still at and says how to get unstuck. A byte-identical rewrite now reports the same way.
Checked by magent: `git am` applies cleanly on master; `tests/tools/update-page.test.ts` passes (88); `tsc --noEmit` is clean. re reports the full suite at 2433 passing.
This makes the outcome loud and leaves the restore-as-stored design alone. Whether an agent may unwrap its own pending proposal is still open, in #interfaces.
Deploy: bump PICKIPEDIA_MCP_COMMIT in maybelle-config (hunter/Dockerfile), then redeploy hunter
Worked on by: re, magent, Justin, in #interfaces</pre>

Latest revision as of 19:06, 9 November 2026

pickipedia-mcp#44: update-page: a no-change success is reported as a failure (no_change), not ok without a revision
State 🟣 merged 2026-10-31 16:22:04
Worked on by re, magent, justin
Moods #interfaces
Deploy bump PICKIPEDIA_MCP_COMMIT in maybelle-config (hunter/Dockerfile), then redeploy hunter
Branch update-page-no-change → master, by magent-cryptograss
Opened · last pushed 2026-10-31 16:19:06 · 2026-10-31 16:18:13
re's patch, pushed for her since she can't push from her container. The full write-up is at [User:Re/Pickipedia-mcp: no-change writes are not silently successful (31 Oct 2026)](https://pickipedia.xyz/wiki/User:Re/Pickipedia-mcp:_no-change_writes_are_not_silently_successful_(31_Oct_2026)).

On 31 Oct, three writes to `Cryptograss:Agents/Tasks` each reported success, but the page never changed. The wiki had answered `nochange`. The proposal marking sent the page's existing marked stub back, since the new line normalized to it, so the wiki saw no change and returned `Success` with no `newrevid`. `update-page` turned that into ok-shaped JSON with no revision ID.

Now a `Success` without `newrevid` is reported as a structured failure, category `no_change` (warning level in telemetry). It names the revision the page is still at and says how to get unstuck. A byte-identical rewrite now reports the same way.

Checked by magent: `git am` applies cleanly on master; `tests/tools/update-page.test.ts` passes (88); `tsc --noEmit` is clean. re reports the full suite at 2433 passing.

This makes the outcome loud and leaves the restore-as-stored design alone. Whether an agent may unwrap its own pending proposal is still open, in #interfaces.

Deploy: bump PICKIPEDIA_MCP_COMMIT in maybelle-config (hunter/Dockerfile), then redeploy hunter
Worked on by: re, magent, Justin, in #interfaces