Host-bound send reports missing AppServerManager after the target processes the message

Version

Codex/AppServer 0.146.0

Impact

A host-bound task send can return:

No AppServerManager registered for hostId

while the exact target nevertheless receives and processes that same message. The sender cannot safely distinguish rejection from delivery-after-error: retrying can duplicate work, while suppressing a retry can lose a genuinely rejected message.

This appears related to, but distinct from, #18556. That issue concerns stale discovered Remote SSH state and startup/reconnect failure. This report concerns truthful send status, host-manager reconciliation, and delivery ambiguity after the effect has occurred.

Minimal natural reproduction

1. Resolve an existing task and its current generic remote-control host binding through supported task metadata.
2. Send one authorized message once, carrying a unique non-private correlation token.
3. Observe the sender returning No AppServerManager registered for hostId.
4. Do not retry and do not use a host-omitted fallback.
5. Observe through the target's ordinary workflow that it received and processed the same correlation.
6. Later metadata may represent the same stable task as local rather than the earlier remote-control binding.
7. Restarting the daemon did not prevent the false-negative behavior from recurring.

Expected

A send should have exactly one truthful outcome:

• accepted, with a stable delivery/correlation receipt;
• rejected before any delivery effect; or
• explicitly indeterminate when the system cannot prove whether an effect occurred.

Stable task identity and the current actionable AppServerManager binding should reconcile atomically.

Actual

The sender reports that no AppServerManager is registered for the supplied host, but the target processes the message. The same task can later surface with a different generic host binding.

No private task IDs, host IDs, paths, payloads, transcripts, logs, credentials, configuration, network names, or project information are included in this report.

Evidence assessment

Confirmed

• Exact host-bound send returned the error above.
• The intended target processed the same correlation.
• No retry or host-omitted fallback was needed for that processing.
• The behavior persisted after a daemon restart.
• The same stable task later surfaced under a generic local binding instead of its prior generic remote-control binding.

Leading hypothesis

Host metadata and the actionable AppServerManager registry can become stale or reconcile non-atomically. Delivery may be accepted before the sender receives a manager/status failure.

Alternatives

• Manager/socket lifecycle changes during routing invalidate the response path after enqueue.
• Remote-control enrollment or proxy state disagrees temporarily with task metadata.

General Wi-Fi failure is not evidenced by this reproduction.

Requested product invariants

1. A stable task identity resolves atomically to exactly one current actionable AppServerManager, or the operation fails before enqueueing any effect.
2. A send never returns a definitive failure after the message may have been accepted or processed.
3. Ambiguous outcomes return an explicit indeterminate state with a correlation receipt.
4. Caller-supplied idempotency/correlation keys survive routing end-to-end.
5. Repeated delivery with the same key cannot process the payload twice.
6. Host migration, reconnect, daemon restart, proxy rebinding, and manager replacement invalidate stale bindings deterministically.
7. Sender and recipient receipts refer to the same stable task, correlation key, and delivery attempt.

Deterministic regression tests

• Remap a task from remote-control to local between metadata resolution and send; assert atomic rerouting or rejection before enqueue.
• Replace/restart the manager after resolution; assert an old binding cannot produce delivery followed by a definitive failure.
• Simulate successful enqueue followed by response-channel loss; assert an explicit delivery-uncertain result with a receipt.
• Remove the manager before enqueue; assert definitive rejection and zero recipient processing.
• Submit the same correlation after an ambiguous result; assert at-most-once processing.
• Exercise local/remote-control binding transitions and assert stable task identity plus current-manager reconciliation.
• Restart with existing tasks and assert stale registry entries are invalidated.
• Assert every sender outcome matches recipient state: accepted, rejected-before-effect, or explicitly uncertain.

Retry and dedupe safety

Until the product can provide a truthful disposition, callers must treat this error as delivery-uncertain and avoid automatic retry or host-omitted fallback.