call_events only captures 'offer' — no duration/outcome from sync --once

[ottsch]

Summary

wacli calls list only ever contains offer events. No accept, terminate, reject, or historical CallLogMessage data is persisted. Duration and outcome are always null.

This appears to be a sync --once limitation: the offer event is queued on the server before the call starts and gets picked up during the next sync, but accept/terminate events happen during the active call when wacli isn't connected.

Evidence

Three inbound calls this month from the same contact, including one that lasted 1h 18m (verified via WhatsApp UI). All three are offer-only:

[
  {"event_type": "offer", "direction": "inbound", "media": "audio", "outcome": null, "reason": null, "duration_secs": null, "timestamp": "2026-05-20T20:23:20Z"},
  {"event_type": "offer", "direction": "inbound", "media": "audio", "outcome": null, "reason": null, "duration_secs": null, "timestamp": "2026-05-19T19:53:42Z"},
  {"event_type": "offer", "direction": "inbound", "media": "audio", "outcome": null, "reason": null, "duration_secs": null, "timestamp": "2026-05-19T18:55:09Z"}
]

Expected

At minimum, duration and outcome should be populated for completed calls. The PR #242 implementation handles both live events and historical CallLogMessage payloads — the question is whether sync --once triggers the app-state sync path that surfaces call-log history.

Possible paths

1. App-state call logs: If CallLogMessage entries exist in app-state but aren't fetched during sync --once, a dedicated calls sync or --include-call-history flag on sync could populate them retroactively.
2. Post-call backfill: A sync --once run after a completed call could check for terminate/historical events that arrived since last sync.
3. Documentation: If this is an inherent limitation of the non-persistent connection model, document it so downstream tools can infer duration from timestamps (e.g., offer → next message gap).

Context

Using sync --once --idle-exit 10s in a cron-based event collector (runs every ~2 min). The downstream consumer (ekku event pipeline) needs call duration to distinguish "had a 1h18m phone call" from "phone rang once" — currently both look identical.

wacli v0.9.2

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this issue: call_events only captures 'offer' — no duration/outcome from sync --once This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.