session: a landing you answered is asked again on the node's next move, and the card never says what became of your answer #1077

Problem

Accept a landed task's your call, look away, come back — the same card is in front of you again, with no answer on it and nothing new under it. Answer it again. It comes back again.

The person who met it: "a question like this keeps coming back even after accepting or answering when we change tabs."

In one session tonight the same landing card was accepted twelve times in an hour, every answer recorded by the engine, and no line anywhere said what the first accept did or why the card was back. The card is the landing question for task 1, "Add open/all source toggle to crew config" — the node whose acceptance check kept running out of time.

The record

The engine's own decision record for that session (~/.codeaf/v3/projects/-Users-santoshkumar-Documents-agentfield-codeaf/292ad97cdbcb0c0e/decisions.jsonl) — one landing question (landing, id 1, decidedBy: person, scope: once, key a = accept) answered twelve times:

The tail clusters seconds apart (18:20:35 → 18:20:49 → 18:21:55 → 18:23:15 → 18:23:22 → 18:26:13). Fourteen seconds and seven seconds are not a settle that ran and came back — that is a card returning faster than any check could have, and a person re-answering it because it looks like their answer was never taken.

Why it happens

A landing question's openness is derived, not stored: OpenQuestions walks "the graph's unverified nodes", and the one door every move of a node goes through is emitTaskUpdate, which ends in publishLandingQuestion (internal/session/task_landing_question.go). Its law — "a node that moves while it is there raises it again with the new shape" — re-raises the question on any notice for a node still in TaskUnverified. Three gaps make that a loop instead of a question:

1. The raise consults nothing about the answer. An answered question is out of the book, so the still-open gate (checkQuestion's "a question that is still on somebody's screen is not asked twice") passes, and the identical question — same token landing:1, same shape, same options — is raised again. PR session, tui3: a task-start question you answered is not asked again when you come back to the tab #1036 built exactly this consultation for the REPLAY (questionAsked naming the card's question, asking saying whether it is still open); the raise door never got one, and EventTaskUpdate is not a card in the backlog switch at all.
2. The card never says what became of the last answer. A re-raise after a genuine re-settle is by design; a re-raise that is indistinguishable from "you never answered" is not. Nothing on the card says accepted 18:20 · the check timed out — accept again, hand it over, or look again, so the honest reading of the twelfth identical card is that the first eleven were ignored.
3. An in-flight accept does not suppress the re-raise. An accept runs a settle — check, then merge. Any notice emitted while that settle runs (an audit retry, a merge round) re-raises the question while the answer's own work is still running, which is how the card is back within seconds of being answered. (This is the reading to confirm first: whether each re-raise rode a settle move, or some fired with no new fact at all.)

What it should be

The re-raise keeps its law — a node that genuinely moved may still owe a person — but the raise owes the record the way the replay owes it: a landing whose question somebody has answered carries that answer's fate on the card (what was answered, when, what became of it), and an accept whose settle is still running holds the question down until the settle lands or fails. The settle guard's spirit, engine-side: a question answered seconds ago is not asked again as though it wasn't.

Related

• session, tui3: a task-start question you answered is not asked again when you come back to the tab #1036 (merged 2026-09-14) — the fix the person remembered: "a task-start question you answered is not asked again when you come back to the tab". It covers the REPLAY half only (questionAsked names five card kinds; the landing re-raise rides EventTaskUpdate, outside that switch), and it carries no tracking issue — which is why this is filed new rather than reopened.
• tasks: an accept whose merge is refused replies "its branch has come home", and the re-landed your-call card has no answers anywhere #767 — "an accept whose merge is refused … the re-landed your-call card has no answers anywhere": the same family, one road of it closed, this road open.
• session, tui3: an attention state (your call) can be drawn with no action a person can take #1069 — the attention-state class: a your call the person is told about with nothing (here, nothing new) to act on.

Severity: serious. Nothing is lost and the work can still land, but a person met this twelve times in an hour of ordinary use, and every answer they gave was recorded while the product behaved as though none had been.

—

Drafted with agentfield ai · reviewed and owned by the author

Drafted with CodeAF · reviewed and owned by the author