tama calls

A broken call is not repeated silently. When a session's call fails (the harness marks its result an error) or a gate refuses it, Tama's common dispatch keeps it for that session, by the call's identity: its tool, its directory and its arguments. It keeps the first line of what answered it (said) and the whole answer as the harness forwarded it (answer), because a failure's operation and cause often stand after its first line. It also keeps when, whether a gate refused it or the call itself failed, and the hook catalog that answered. The same call of the same session is then refused before any hook runs, quoting that answer, until something that could change the answer happened:

• the session changed a file: a write or edit of the session succeeded after it (this releases every call the session kept);
• the hook catalog that refused it was replaced by another release, or a judgement answer was kept on this machine since the refusal (tama judgement ask), so the gate that lacked one may decide it now (a call a gate refused only);
• Oko holds an open defect that binds the call's functionality: from then on the defect gate decides the call, and the defect's owner runs it only while its declared work for the operator's current instruction is that defect (tama task scope set --session <owner> --defect <id>, declared again after a newer instruction), to repair it. A closure of a defect that binds the call is the defect having left Oko's open snapshot, the source the defect gate admits by (a fix Oko holds claimed and not yet verified keeps it there), named by the newest lifecycle event Oko kept when it fixed or withdrew it: <defect id>@<event id>. Each fix or withdrawal is its own event, so a defect reopened and closed again in the same second is a new closure; a defect closed before Oko kept lifecycle events has no closure event and releases nothing. A failed or refused call keeps every such closure that exists when it is kept (closures), together with those its earlier record held, and only a closure outside that list is a change since: the call runs again once, whether or not the session called it while the defect was open, and every such closure is added to the list before it runs, so a repeat that fails again is held again. A call kept before closures were accounted has no list: the closures that exist when it is next asked become its list and it stays held, so a closure older than its failure never releases it. No time is compared. Only a call that failed or was refused reads Oko's register for this. A register that cannot be read or decoded refuses the call as TAMA_HOOK_INFRASTRUCTURE: the repeat gate cannot read|decode Oko's register <path>: …;
• the session said why the repeat differs, with tama calls retry. The reason is kept with the call and lifts only this hold on repeating it unchanged. Every other gate still decides the next call, and an open defect that binds it still refuses it. A repeat that fails again is kept again.

A changed call, and the same call of another session, are their own calls and are not refused. A call that succeeds is no longer kept. The refusal names these ways out, so a repeated failure becomes work on its cause or the one defect that binds the broken functionality (oko defects record … --blocks "PROGRAM WORDS", which Oko refuses when an open defect already binds it and names that defect instead).

A call whose result never came back is kept too. Every call the gates admit is kept as started in ~/.tama/started-calls/<session>.json until its result comes back, and any result, failed or not, settles it. When the session sends the same call while an earlier one is still unsettled (it hung until it was interrupted, its process was killed, or its harness ended before it answered), that earlier one is kept as failed with by unanswered, at the time it started and said it started at <time> and its result never came back: …, and the call now sent is refused like any failed call, so a command that hung for minutes is not started again unchanged. The closures it accounts for are those existing when it is found unanswered. A result of the earlier call that does come back later settles it as any result does.

#Invocation

tama calls failed --session <id>
tama calls retry <call> --session <id> --because <what changed>

• failed prints {"calls": {"<call>": {"tool", "said", "answer", "by", "at", "catalog", "answers", "retry", "closures"}}} from ~/.tama/failed-calls/<session>.json; a session that kept none prints no calls. A call kept before whole answers were kept carries an empty answer; closures lists the closures of defects binding the call that its failure accounts for.
• retry keeps the reason with the call and prints {"session", "call", "failed"}. The next dispatch of that call is no longer held for repeating, and every other gate still decides it.

#Output and refusals

• The repeated call is refused as this session's same call was <failed|refused|unanswered> at <time>: <first line>. Repeated unchanged it gets the same answer and the failure stays unconnected. …, followed by Its whole answer was: and that answer when it holds more than its first line. Its document carries call and failed.
• calls: session <id> keeps no failed call <call>; `tama calls failed --session <id>` lists them, calls: tama calls retry --because takes what changed since the call failed; it was empty, and an unreadable or undecodable record naming its path, exit 1.
• A missing verb, --session, call or --because prints the usage on stderr, exit 2.
• A record that cannot be read refuses the call as TAMA_HOOK_INFRASTRUCTURE: … naming the path and cause; a record that cannot be written after a dispatch is said on the core's stderr and does not change that dispatch's decision.

#Native interface and desktop

The native request interface answers calls/failed with a body naming session, and calls/retry with session, call and because; an empty field is refused as <operation> needs a nonempty <field>. In Tama Desktop, Install plan → Failed calls takes the session. Read failed calls lists each kept call with its tool, how and when it failed, its first line and, below it, the whole answer when that holds more. Retry with this reason keeps the reason typed above, says The reason was kept: the hold on repeating this unchanged call is lifted until it fails again. Every other gate still decides the next call, an open defect that binds it among them., and reads the calls again. A call released this way shows Repeat hold lifted (other gates still decide): <reason>. A refused read after a kept retry names the read (Failed calls [calls/failed]: …), not the retry.

#Real qualification

tests/repeated-calls/journey.rs starts the built tama run-hook --serve omp core in its own home, dispatches a failed bash result as the OMP adapter forwards it, and checks the refusal of the unchanged call, the pass of a changed call and of another session's call, tama calls failed, the usage refusal and release of tama calls retry, a second failure kept again, and the release by a successful write. Its unanswered leg dispatches an admitted call with no result, then the same call again, and checks the refusal naming unanswered and the start, the record in tama calls failed, and that a call whose result came back is not held.

Return to the complete CLI tree.