asks: a replayed tap is said as the answer already recorded (issue 393) #78

2026-10-10T16:22:32Z

mesh-admin commented

2026-10-10 16:22:32 +00:00

Fixes issue 393 (mesh-lab's asks check fails, so every mesh-lab pull request is red).

Cause: the proof from #74 waited for a chat message 'That answer was not taken' after a replayed Approve tap. Since issue 372 (mesh-catalog #175, review commit 35c4de7) the router answers the same answer again from the same account with 'You already chose Approve at HH:MM: recorded.' (confirmAgain), and the channel says it on the tap's acknowledgement (answerCallbackQuery), not in the chat. The lab's fake Telegram kept no acknowledgement words.

Change: the fake Telegram keeps a tap's acknowledgement words by the chat the tap came from, apart from the chat's messages (so the stranger/group checks of subtest 5 are unchanged), and shows them in the transcript. The replay subtest waits for 'You already chose Approve … recorded' there; its checks that the router said one word on the ask, that a redelivered warrant is Done, and that the act ran once are unchanged.

Tested: MESH_LAB_REPOS=<clones of main> sh asks/merge-check.sh passes, all 9 subtests (186 s); before the change the replay subtest failed exactly as on the build seat.

Fixes issue 393 (mesh-lab's asks check fails, so every mesh-lab pull request is red). Cause: the proof from #74 waited for a chat message 'That answer was not taken' after a replayed Approve tap. Since issue 372 (mesh-catalog #175, review commit 35c4de7) the router answers the same answer again from the same account with 'You already chose Approve at HH:MM: recorded.' (confirmAgain), and the channel says it on the tap's acknowledgement (answerCallbackQuery), not in the chat. The lab's fake Telegram kept no acknowledgement words. Change: the fake Telegram keeps a tap's acknowledgement words by the chat the tap came from, apart from the chat's messages (so the stranger/group checks of subtest 5 are unchanged), and shows them in the transcript. The replay subtest waits for 'You already chose Approve … recorded' there; its checks that the router said one word on the ask, that a redelivered warrant is Done, and that the act ran once are unchanged. Tested: `MESH_LAB_REPOS=<clones of main> sh asks/merge-check.sh` passes, all 9 subtests (186 s); before the change the replay subtest failed exactly as on the build seat.

mesh-admin added 1 commit 2026-10-10 16:22:32 +00:00

asks: a replayed tap is said as the answer already recorded, on its acknowledgement (issue 393)

mesh/merge-gate pass: the change touches no module of the mesh's graph

Details

mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript), replays/merge-check.sh (go), asks/merge-check.sh …

Details

mesh/delivery delivered

Details

af0a32a780

Since issue 372 the router answers the same answer again from the same
account with 'You already chose Approve at HH:MM: recorded.', on the
tap's acknowledgement rather than in the chat. The proof from #74 still
waited for a chat refusal, so it failed on every mesh-lab pull request.
The lab's phone now keeps a tap's acknowledgement words, and the replay
subtest waits for them; its checks that nothing more is done stay.

mesh-admin commented

2026-10-10 16:23:08 +00:00

Delivery novox/mesh-lab@af0a32a780a7 — delivered since 2026-10-10T16:27:34Z

Delivery plan — builds nothing: the change touches no module of the mesh's graph

Transitions

2026-10-10 16:23 (new) → proposed (announced): novox/mesh-lab#78's head announced
2026-10-10 16:26 proposed → checked (checked): the verdict names this commit
2026-10-10 16:26 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-10 16:27 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-10 16:27 published → delivered (done): nothing for a walk to move

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-lab@af0a32a780a7` — **delivered** since 2026-10-10T16:27:34Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Transitions** - 2026-10-10 16:23 (new) → proposed (announced): novox/mesh-lab#78's head announced - 2026-10-10 16:26 proposed → checked (checked): the verdict names this commit - 2026-10-10 16:26 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-10 16:27 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-10 16:27 published → delivered (done): nothing for a walk to move The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

mesh-admin commented

2026-10-10 16:23:34 +00:00

Review: APPROVED at af0a32a

Not weakened. The new expected words are what the router deliberately says since issue 372: judge in modules/messenger/cmd/messenger/asks.go calls confirmAgain ("You already chose at HH:MM: recorded.", with Reply set to the tap) when the same option comes again from the same account. The telegram channel's Take settles that reply on the tap via settleTap -> AnswerTap (answerCallbackQuery) and sends nothing to the chat, because the body is empty. The old "That answer was not taken" was the bug that issue 372 fixed. The subtest still checks that the router said one word on a1, that a redelivered warrant is Done, and that performed has length 1. The matcher requires both "You already chose Approve" and "recorded", so a refusal cannot satisfy it.
Other subtests are unchanged. Acknowledgement words go to toasts, apart from sent. since and waitFor still read only sent, so subtest 5's stranger and group checks mean what they meant before. toldTapper reads both lists, so it would also accept the words if a future channel said them in the chat.
Correctness: tappedIn is created lazily under f.mu and filled before push, and both maps are read under f.mu. toldTapper copies the lists into a fresh slice before appending, so it does not alias f.sent. gofmt and go vet are clean.
Words: no retired glossary words appear in the added lines or the PR text.
Secrets: none.

Nit, not blocking: an acknowledgement shown to a stranger or in a group is now recorded but not asserted against in subtest 5. That gap existed before this change and could be closed with a follow-up check on toasts.

Review: APPROVED at af0a32a 1. Not weakened. The new expected words are what the router deliberately says since issue 372: `judge` in modules/messenger/cmd/messenger/asks.go calls `confirmAgain` ("You already chose <label> at HH:MM: recorded.", with Reply set to the tap) when the same option comes again from the same account. The telegram channel's `Take` settles that reply on the tap via `settleTap` -> `AnswerTap` (answerCallbackQuery) and sends nothing to the chat, because the body is empty. The old "That answer was not taken" was the bug that issue 372 fixed. The subtest still checks that the router said one word on a1, that a redelivered warrant is Done, and that performed has length 1. The matcher requires both "You already chose Approve" and "recorded", so a refusal cannot satisfy it. 2. Other subtests are unchanged. Acknowledgement words go to `toasts`, apart from `sent`. `since` and `waitFor` still read only `sent`, so subtest 5's stranger and group checks mean what they meant before. `toldTapper` reads both lists, so it would also accept the words if a future channel said them in the chat. 3. Correctness: `tappedIn` is created lazily under `f.mu` and filled before `push`, and both maps are read under `f.mu`. `toldTapper` copies the lists into a fresh slice before appending, so it does not alias `f.sent`. gofmt and go vet are clean. 4. Words: no retired glossary words appear in the added lines or the PR text. 5. Secrets: none. Nit, not blocking: an acknowledgement shown to a stranger or in a group is now recorded but not asserted against in subtest 5. That gap existed before this change and could be closed with a follow-up check on `toasts`.

mesh-admin merged commit c48d68ac92 into main

2026-10-10 16:27:21 +00:00

mesh-admin deleted branch fix/393-asks-replayed-tap

2026-10-10 16:27:21 +00:00

jschoubben referenced this issue from a commit

2026-10-10 16:27:52 +00:00

Merge main into replay/368: the asks check fixed for issue 393 (#78)

mesh-admin referenced this pull request

2026-10-10 16:27:56 +00:00

Register R368: a moved path is no shrink, and a shrink at the new path still is (hq issue 368) #77

Sign in to join this conversation.