[pufit]

What

The record of a GitHub notification with reason mention now says whether the update itself mentions the account.

• mention: new in the metadata: something posted since the readers of the inbox last read a record of the thread mentions the account. With mention_at, and with mention_by and mention_url when the source read the text. The text is quoted in the content under --- Mention ---.
• mention: old: nothing new mentions the account, and an earlier mention (mention_at) explains GitHub's reason. The summary line ends with (update, no new mention) instead of (mention).
• No mention key: not known. The record is what it was before this change.

reason stays mention in all three cases, so allow_reasons and deny_reasons work as before.

Why

GitHub's reason belongs to the thread, not to the update. Its REST documentation says: "The reason remains as mention, regardless of whether you're ever mentioned again." So one mention makes every later comment on that thread arrive as mention, for months.

A reader of the inbox could not tell the difference. The summary line and the metadata said mention, and the content is condensed for long records, so the comment behind the update was usually not in it.

Measured on one account over two weeks: 19 threads arrived with reason mention. In 18 of them the latest update did not mention the account; the mentions that set the reason were from hours to months old.

How

For an issue or a pull request with reason mention, the source reads what was posted since the readers of the inbox last read a record of the thread.

Text	Checked against
Description and comments	GitHub's own mention events of the thread (one GraphQL call, newest first)
Reviews and inline review comments of a pull request	Their text: a whole @login outside Markdown code

The two differ because GitHub writes no mention event for a mention in a review or in an inline review comment, though it notifies. Measured on live threads: 30 of 30 mentions in comments had a mention event, and 0 of 6 mentions in reviews and inline review comments had one. Where timed (29 mentions), the event came 1 to 3 seconds after the text. The events also date a mention that an edit added.

Evidence only. A record is marked old only when every read succeeded and an earlier mention of the account was found. If the login cannot be read, a read fails, or no mention is found at all, the record keeps GitHub's mention unchanged. A failed read cannot hide a mention.

The login is the account gh acts as. It is read in every run that has such a thread and never kept between runs, so another account, or a renamed one, is used from the next run on. The GitHub events source kept its looked-up login for the life of the process; it now reads it in every run too and falls back to the last answer when a read fails.

New until read. Storage keeps one record per thread and replaces it when the thread moves, and the source runs more often than the inbox is read (by default every 15 minutes against every 30). A record that says new can therefore be replaced before any reader saw it. So "new" is counted from the last record of the thread that every live consumer of the source has read: the record that replaces an unread new still says new, with the mention text, and a record says old only after a reader has read the mention. A consumer that stopped reading counts until its cursor expires (2 days by default); until then a mention can be new again in later records of the thread, with the same mention_at.

The source gets the read state from storage (unread_source_message_metadata, one query per run). Where each look at a thread ended is remembered in the process (the latest 2048 threads). A thread listed again with the same updated_at is checked from the same moment as the first time, so its record comes out identical and storage skips it. After a restart, a thread is checked for the time since the sync cursor, and no later than a mention that an unread record says is new.

Also fixed

The "recent comments" of a record were the ten oldest comments of the thread. The listing of one thread's comments takes no sort order: sort=created&direction=desc is ignored there and the oldest come first. The source now lists the comments with since, from the last record that the readers have read, and shows the human ones newest first under --- New Comments ---.

Not changed

• team_mention, and subjects other than issues and pull requests, are not checked.
• The hosted GitHub source is not touched: its records are built from single events.
• A mention in a review comment that is older than the newest 100 inline comments or 50 reviews is not found. Such a thread keeps mention.

Tests

tests/test_github_source_mentions.py (71 cases): new, old and unknown answers; reviews and inline comments; failed reads; paging of the mention events and of the comments; the same update listed twice; a mention that stays new until a reader has read it, also through the source runner and storage (two source runs between two reads of the inbox); the read state in storage; the login read per run and a change of account; the events source.

The existing GitHub source and source runner tests pass unchanged.

Also run read-only against a live account: of five threads listed with reason mention, the one whose latest update mentioned the account came out new with its author and link, and the other four came out old with the date of their last mention. A second run from the same cursor produced identical records.

Generated by Nerve

[nerveai]

Nerve PR review · ✅ Ready to merge

Updated for da64ff7: this commit fixes the earlier blocking point. Before, a new mention could be replaced by a later update before anyone read it. Now, while any live consumer has not yet read a thread's stored record, the next look starts where that record's look started (nerve/sources/github.py:941-955). So the replacing record still says new and still quotes the mention. The read state comes from one query per run, which compares the consumer cursors with the record's rowid (nerve/db/sources.py:456-484). The comparison holds because storage re-inserts a changed record above every cursor (nerve/db/sources.py:164-185). The query is wired in for the polled source only (nerve/sources/registry.py:170-177). When the read state can't be read, every record counts as unread, so a mention may be repeated but is never lost. After a restart, the window reaches back to an unread new mention.

Overall this is a useful, well-bounded change: reason stays as it is, so the guardrails behave as before, and a record moves to old only on evidence.

Completeness: tests cover both the run/read interleaving and storage. One test drives two source runs between two inbox reads through SourceRunner and storage. Docs explain "New until read" and the cursor-TTL trade-off. No config or migration changes.

_{Checked: full suite in an offline sandbox at da64ff7 (3 chunks): 9028 passed, 39 skipped; test_slack_integration.py excluded (hangs offline on main too). CI green. Trial merge into main is clean, with no conflict with #677, #679, #596, #487 or #429. Read the new read-state path, the storage re-insert and the cursor expiry · automated review by nerveai — mention @nerveai to ask a follow-up.}