Chat: messages the manager sends do not appear in his own log (recipient receives them) #23

New issue

Open

opened 2026-10-29 19:35:02 +00:00 by rosa · 1 comment

rosa commented

2026-10-29 19:35:02 +00:00

Member

Symptom (manager-reported, three separate days): messages Felix sends from the chat UI do not appear in his own message log after sending. They appear later, or after a refresh — and the recipient receives them normally.

Reported by felix (quoted from the inbox as read 2026-10-29 19:32Z):

26 Oct 22:37Z: "There was a bug where the webui didnt show the messages I send to you for like 10 minutes then suddenly they all appeared"
27 Oct 07:30Z: "No i just send another message and it doesnt show up for me"
27 Oct 09:17Z: "No still ui doesnt Show me Messages i sent or recent Messages at all"
29 Oct 19:26-19:27Z: "Test Message" / "Why are my Messages again Not showing Up in the log" / "Like i am sending this can See them once they are send"

What the evidence narrows to:

Transport works: the agent side can list exactly these messages, including the "Test Message" itself. So delivery is not the failure.
The gap is the sender's own view — the local echo / publication path that should render his just-sent message into his log.
He now sends "Test?" repeatedly to find out whether anything went through. Not cosmetic: he has no visible confirmation that his instructions were delivered.

Related history (from our own notes, not re-measured here): after R87/R88 (mongodb pin + local replica set, merged 23 Oct) local oplog delivery was recorded at ~1s, and he still reported no live visibility of his sent messages afterwards. So either the echo path was never covered by that fix, or it regressed.

Cause NOT determined — deliberately. Questions for whoever picks this up, cheapest first:

Does the client add an outgoing message optimistically, or wait for a publication it isn't subscribed to?
Is the subscription delivering own-sent messages filtered differently from inbound ones (sender == self)?
Does it reproduce with oplog tailing active — same class as the pinned-mongo drift, or separate?

Worth capturing when reproducing: which client (web UI / Teams / mobile), whether a hard refresh shows them immediately or they still arrive late on their own, and how long "late" is.

Filed by rosa 2026-10-29, from inbox state read at 19:32Z. No code changes proposed here.

**Symptom (manager-reported, three separate days):** messages Felix sends from the chat UI do not appear in his own message log after sending. They appear later, or after a refresh — and the recipient receives them normally. Reported by felix (quoted from the inbox as read 2026-10-29 19:32Z): - 26 Oct 22:37Z: "There was a bug where the webui didnt show the messages I send to you for like 10 minutes then suddenly they all appeared" - 27 Oct 07:30Z: "No i just send another message and it doesnt show up for me" - 27 Oct 09:17Z: "No still ui doesnt Show me Messages i sent or recent Messages at all" - 29 Oct 19:26-19:27Z: "Test Message" / "Why are my Messages again Not showing Up in the log" / "Like i am sending this can See them once they are send" **What the evidence narrows to:** - Transport works: the agent side can list exactly these messages, including the "Test Message" itself. So delivery is not the failure. - The gap is the *sender's own view* — the local echo / publication path that should render his just-sent message into his log. - He now sends "Test?" repeatedly to find out whether anything went through. Not cosmetic: he has no visible confirmation that his instructions were delivered. **Related history (from our own notes, not re-measured here):** after R87/R88 (mongodb pin + local replica set, merged 23 Oct) local oplog delivery was recorded at ~1s, and he still reported no live visibility of his sent messages afterwards. So either the echo path was never covered by that fix, or it regressed. **Cause NOT determined — deliberately.** Questions for whoever picks this up, cheapest first: 1. Does the client add an outgoing message optimistically, or wait for a publication it isn't subscribed to? 2. Is the subscription delivering own-sent messages filtered differently from inbound ones (sender == self)? 3. Does it reproduce with oplog tailing active — same class as the pinned-mongo drift, or separate? **Worth capturing when reproducing:** which client (web UI / Teams / mobile), whether a hard refresh shows them immediately or they still arrive late on their own, and how long "late" is. Filed by rosa 2026-10-29, from inbox state read at 19:32Z. No code changes proposed here.

rosa commented

2026-10-29 19:40:33 +00:00

Author

Member

Update 29 Oct 19:38Z — manager narrowed the symptom himself: "Sry false Alarm my Messages now Show Up they just Take a while".

So the messages are not lost: own-sent messages eventually render. That makes this a latency / delayed local echo bug, not a dropped-publication bug, and it matches his 26 Oct wording ("for like 10 minutes then suddenly they all appeared" -- a burst, which looks like a catch-up rather than a stream).

Two consequences worth keeping in the scope of this issue:

He cannot tell in the moment whether an instruction landed, so he sends "Test?" repeatedly. The visible symptom is delay; the real cost is lost confidence in the control channel.
On the agent side this shapes verification duty: an apparently empty inbox may simply be delayed, so a conclusion like "nobody asked anything" must come from a full unfiltered read, not a filtered/tail view (a sender-filtered check did miss his newest message today; the unfiltered one returned it). Any subscription/timeout work should make client-side delivery monotonic and quick enough that the UI is trustworthy as a receipt.

Status: keeping OPEN - the delay itself is the bug and is still present. No cause identified yet; the three diagnostic questions above stand. — rosa

**Update 29 Oct 19:38Z — manager narrowed the symptom himself:** "Sry false Alarm my Messages now Show Up they just Take a while". So the messages are not lost: own-sent messages eventually render. That makes this a *latency / delayed local echo* bug, not a dropped-publication bug, and it matches his 26 Oct wording ("for like 10 minutes then suddenly they all appeared" -- a burst, which looks like a catch-up rather than a stream). Two consequences worth keeping in the scope of this issue: 1. He cannot tell in the moment whether an instruction landed, so he sends "Test?" repeatedly. The visible symptom is delay; the real cost is lost confidence in the control channel. 2. On the agent side this shapes verification duty: an apparently empty inbox may simply be delayed, so a conclusion like "nobody asked anything" must come from a full unfiltered read, not a filtered/tail view (a sender-filtered check did miss his newest message today; the unfiltered one returned it). Any subscription/timeout work should make client-side delivery monotonic and quick enough that the UI is trustworthy as a receipt. Status: keeping OPEN - the delay itself is the bug and is still present. No cause identified yet; the three diagnostic questions above stand. — rosa