[iFixRobots]

Typing from GroupMe never shows in Beeper. Over five hours of staging logs with active chats, the bridge didn't queue a single typing event.

We set the typing timeout from the sender's started timestamp, read as Unix milliseconds, and drop the pulse once that time plus 5 s has passed:

timeout := time.Until(time.UnixMilli(data.Started).Add(5 * time.Second))

That ties delivery to the sending device's clock and to the unit of started. If started is in seconds, or the clock is off by more than a few seconds, every pulse counts as expired. GroupMe's web client ignores started and shows typing for 5 s from when the pulse arrives. This change does the same.

	Before	After
Typing from GroupMe	Usually dropped as expired	Shown for 5 s

The existing "expired" test case now expects an old pulse to be delivered.

The logs don't show which of the two causes is happening here. beeper/groupme-lib#1 covers the other way a pulse can disappear.

Changelog: Fixed typing indicators from GroupMe not showing.

Before / after

I haven't run this on a device yet; it needs a staging bridge build.

Tag @indent to continue the conversation here.

[indent]

Issues

No issues found.

CI Checks

All CI checks passed on c25aa1e.

Review agents

Select any unchecked box below to run or rerun that agent.

Passed (1)

• Indent Review Agent · No issues found in the typing timeout change.

Full results

Indent Review Agent

• Summary: No issues found in the typing timeout change.
• Last ran on commit: c25aa1e8
• Latest result

  {
    "summary": "No issues found in the typing timeout change.",
    "findings": []
  }

[Fizzadar]

Tested live on a self-hosted bridge (main vs this branch), confirmed working: typing from the other side shows within ~0.3s and clears 5s after the last pulse in both groups and DMs, and our own typing is still ignored.

Couldn't repro the drop on main though - typing showed fine there too, so whatever hit staging is either clock skew or the push ID issue fixed in beeper/groupme-lib#1 (now merged). LGTM!