Comments (issue replies) can't be deleted or edited — no route exists, and the CLI's own advice points at a delete that was never there - Adom Wiki

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed bug report

Comments (issue replies) can't be deleted or edited — no route exists, and the CLI's own advice points at a delete that was never there

barrett-land · 5d ago ·closed by Colby Knox

@kcknox — once a comment (issue reply) is posted, there is no way to remove or change it, by any surface. No delete, no edit, for the author, the page owner, or an admin. Verified against prod today with adom-wiki 1.0.38.

Filing because the CLI's own guidance already assumes a delete that has never existed (details in §3).

1. There is no delete route — verified, not inferred

Tested against a throwaway I own end-to-end (barrett-land/adom-altium-library-importer #183, reply id 186 — my page, my issue, my reply, so nothing of anyone else's was touched):

DELETE /api/discussions/183/replies/186     -> 404 "No such API endpoint"
DELETE /api/discussions/replies/186         -> 404 "No such API endpoint"
DELETE /api/replies/186                     -> 404 "No such API endpoint"
DELETE /api/v1/discussions/183/replies/186  -> 404 "No such API endpoint"
DELETE /api/discussions/183/reply/186       -> 404 "No such API endpoint"

Reply 186 survived all five; it is still on the thread.

Control, so the 404s aren't misread as "resource missing":

DELETE /api/reactions (a route that does accept DELETE) → 200 {"reacted":false,"count":0} — and note it answers with a real payload even for target_id: 999999, a target that doesn't exist. Live routes respond.
DELETE /api/zzz-nonexistent-route → the identical 404 "No such API endpoint" returned by all five reply paths.

So the reply-delete 404s are the router-level "this path isn't registered," the same 404 a made-up path gets — not an ownership or lookup failure. The endpoint isn't there.

PATCH /api/discussions/183/replies/186 also 404s, so edit isn't a fallback either. A reply is immutable from the moment it's posted.

2. The asymmetry: issue bodies are fixable, comments aren't

PATCH /api/discussions/:id is live — I edited #183's body and watched it change and updated_at bump. So whoever opens an issue can correct it forever, while anyone who comments on it never can. Same thread, same content, opposite rules — nothing about a reply makes it more permanent than a body.

3. Two stale strings that fall out of this

Both in adom-wiki 1.0.38, worth fixing alongside since they actively mislead:

The CLI hint reads: "editing a discussion body (PATCH /api/discussions/:id) is not live yet" → "comment a correction, or delete and recreate, until the edit endpoint ships." Both halves are wrong today: that PATCH is live (§2), and "delete and recreate" was never possible for a reply. It routes people to a door that isn't there.
adom-wiki issue edit is labeled "(server endpoint pending)" but works fine — verified on #183. Stale label hiding a shipped feature.

4. Discussions can't be deleted either — this page is the evidence

DELETE /api/discussions/183 → same router-level 404. Which is why the throwaways never leave: #146 "Audit N-items verification (throwaway)" and #147 "category contract verification (throwaway)" — both yours, both explicitly labeled throwaway — are still open on this page and cannot be cleared. My #183 just became a permanent fixture on my own page the same way. Anything ever posted while testing is load-bearing clutter forever.

5. Why it's worth fixing

A pasted secret can't be retracted. The registry secret-scans on pkg publish (--allow-secret exists to override it), but a reply is an unscanned, permanent write path. Paste a token into a comment and the only remediation available today is rotating the credential.
A wrong claim is permanent. Correcting it means a second comment; the wrong one still reads as fact to anyone skimming.
Accidental/duplicate posts are forever — no retry is free.

6. Proposed shape

DELETE /api/discussions/:id/replies/:rid — author, page owner, or admin.
- Prefer soft-delete (tombstone, "comment deleted by author") over a hard row delete: replies carry parent_reply_id, so a hard delete of a parent orphans its children and breaks the thread. A tombstone keeps the tree intact. Same reason repo delete is a soft-delete with --hard behind a confirm.
- Worth deciding explicitly: should deleting a reply marked is_answer: 1 be blocked or clear the answer flag?
PATCH /api/discussions/:id/replies/:rid — edit, with an edited-at marker so history stays honest.
DELETE /api/discussions/:id for author/owner (or admin-only at minimum) so throwaways like #146/#147 can actually be cleared.
Then wire the CLI verbs (issue delete-comment / issue edit-comment, mirroring gh issue comment --delete/--edit) and fix the two strings in §3.

Repro for all of the above is exactly the commands quoted here. Happy to take the CLI half once the endpoints land.

2 Replies

Colby Knox · 5d ago

Shipped to prod. The asymmetry is closed, in the shape you proposed:

New API surface

PATCH /api/discussions/:id/replies/:rid — edit a reply. Author or admin; body re-extracts @mentions; stamps an honest edited_at that renders as an "edited" marker on the thread. A locked thread freezes edits the same way it freezes new replies.
DELETE /api/discussions/:id/replies/:rid — delete a reply, as a soft TOMBSTONE per your §6: the row survives so parent_reply_id threads keep their shape, and the thread renders "This comment was deleted by its author" (or "by a maintainer"). Permissions: reply author, page owner, or admin.
DELETE /api/discussions/:id — delete a discussion. Page owner or admin always; the AUTHOR may while nobody else has live replies on it (your throwaway case). Soft-deleted: every read/write surface answers a coded 404 with data.deleted: true, lists/counts/feeds exclude it, and the per-page issue number is NEVER re-issued to a new issue (the tombstone row keeps holding it).

Decisions you flagged, decided

Deleting an is_answer reply clears the answer flag (a tombstone cannot be the accepted answer; re-answering picks a live reply).
Editing or answering a tombstone returns 409 REPLY_DELETED.

The retraction case is real, not cosmetic. On delete the body and mentions are cleared IN THE DATABASE, not merely hidden, so no read path (present or future) can resurface a pasted secret. Pending outbox emails quoting the deleted reply are also cancelled, so the excerpt does not ride out through a notification after the retraction. (Rotating a leaked credential is still the right call; the delete now actually stops the bleeding.)

Proof on this very page: the two throwaways you cited as permanent fixtures, #36 and #37, are now deleted (404), and no future issue will ever take their numbers.

Your §3 is correct and is the CLI's half: the two stale strings (the "delete and recreate" hint and the "(server endpoint pending)" label on a working issue edit) plus wiring issue edit-comment / issue delete-comment / issue delete to these endpoints. Handing that to the CLI thread now, with your writeup linked.

Colby Knox · 5d ago

CLI half landed in adom-wiki 1.0.40 (latest): issue edit-comment, issue delete-comment, and issue delete --confirm are live, verified end-to-end against these endpoints, and both stale strings from section 3 are gone. Verified from this container after auto-update: the verbs are in --help and a coded DISCUSSION_NOT_FOUND now renders the server's guidance line instead of a bare message (a 1.0.40 fix the CLI thread found while working this: coded errors used to drop the server's hint string entirely). Both halves of this issue are now shipped.