Telegram forum topic opens then never updates: later frames rejected as trusted attachment lease is stale

[project-catsy]

Description

On gjc/0.14.0 (Telegram daemon generation 169), starting a new interactive session creates a Telegram forum topic and posts the identity header, then no later conversation frames are delivered. The topic looks opened and then frozen.

This is not BotFather / Threaded Mode / chatId misconfiguration. The topic is created. Identity is sent. Every subsequent publication is rejected before send.

Observed on a live session 01a010b5-a66f-7000-800f-497c9708882a (topic 2067, title Telegram session chat not updating):

• telegram-topics.json: identitySent: true, replaySeq: 2
• telegram-presentation-state.json: only :1:2 delivered; :1:1 and :1:3 through :1:59 all rejected
• daemon health stayed green (ownershipPhase: ready, attachments present)

This is distinct from #4527 (outbound freeze after session-host handoff with no attach). Here the attachment is live, identity publishes, and later frames fail closed on the trusted-lease gate.

Steps to Reproduce

1. Install gjc/0.14.0. Enable Telegram notifications with a complete bot token + private chat id, Threaded Mode on.
2. Confirm the Telegram daemon is running (gjc daemon status). At the time of the incident: generation 169, serving epoch 87.
3. Start a new ordinary interactive session (gjc in a repo). Do not use /notify off.
4. Watch Telegram: a new forum topic appears and the identity header is posted.
5. Continue the session (prompt, tools, turn stream). Wait past the 20s topic-host lease TTL if the first live frames are delayed (lean/idle batching makes this easy).

Expected Behavior

After the topic and identity header are created, later turn_stream / context_update / tool frames for that live trusted attachment should publish into the same topic. Heartbeat should keep renewing the host lease for a still-attached owner.

Actual Behavior

Identity (:1:2) is the only delivered publication. Later frames are rejected before Bot API send. The topic never updates.

Root cause in installed 0.14.0 telegram-daemon.ts:

1. Attachment starts with logicalSessionIdTrusted = false. #leaseAllows() returns true in that window, so createForumTopic + identity can send.
2. After Router replay, logicalSessionIdTrusted = true. Later frames require an authorized recovery lease and a non-expired topic host lease (leaseExpiresAt > now, TTL = HEARTBEAT_TTL_MS = 20s).
3. renewActiveTopicLeases() only renews sessions that already pass #leaseAllows(). Once the host lease expires, renewal is skipped forever.
4. handleSessionMessage then throws:

Telegram publication rejected before send: trusted attachment lease is stale

Generation 156 made ordinary interactive sessions topic-eligible. That is why the room now appears. The trusted-lease / renewal cycle was not fixed with that change, so the newly eligible path dies after identity.

Error Output

Exact warn from ~/.gjc/logs/gjc.2026-08-18.log (pid 22650 is the Telegram daemon):

{"timestamp":"2026-08-18T02:12:08.747+09:00","level":"warn","pid":22650,"message":"SDK notification subscription notification:01a010b4-ae6e-7000-b6ed-d1b916fa263a:d3a7b01f-d87f-48eb-8195-570e4b788fee failed locally: Telegram publication rejected before send: trusted attachment lease is stale"}

Same session that created the identity-only topic (01a010b5-…8882a) then rejected every later publication id :1:3 … :1:59 in telegram-presentation-state.json. Topic record after the freeze:

{
  "topicId": "2067",
  "identitySent": true,
  "replayGeneration": 1,
  "replaySeq": 2,
  "authorityState": "disconnect_grace",
  "leaseExpiresAt": 1786986857311
}

Fail site (installed 0.14.0):

if (session.logicalSessionIdTrusted && !this.#leaseAllows(session))
  await this.#failPublicationPreSend(publicationId, "trusted attachment lease is stale");

#failPublicationPreSend marks the publication rejected and throws Telegram publication rejected before send: ${reason}.

Platform

macOS (darwin 25.5.0, arm64)

gjc version

gjc/0.14.0

Bun version

1.3.14

Provider

Not provider-specific. Session used xAI Grok 4.6 for title generation; the Telegram failure is in the notification daemon, not the model path.

Area

Other (Telegram notification daemon / forum topics)

Additional context

• Daemon at incident: generation 169, serving epoch 87, chatId paired and creating topics successfully.
• Local checkout of this repo is still generation 151 and contains the same #leaseAllows + reject string. The 160–169 daemon cleanup (orphan reap, ownership-off-critical-path, eligibility from config) does not fix this. Restarting/reaping the daemon only recreates identity-only topics.
• Suggested fix: split socket authority from host-lease TTL. Heartbeat and pre-send should renew an owned topic lease even after expiry, then re-check #leaseAllows. Confirmed locally: after that change, a new interactive session updates the Telegram topic past identity.
• Related but not the same: telegram daemon: outbound publications freeze after session-host handoff; health stays green #4527 (attach/reconcile hang, no identity). Generation 156 changelog (“Telegram notifications are delivered again… ordinary interactive session declared itself topic-ineligible”) is the precursor that exposes this next gate.

[Yeachan-Heo]

Fix for this issue is up as PR #4648 (branch fix/issue-4647-telegram-lease), exact head 2adf6f7d79c1de822193e0709128cc0e00f98207 rebased onto current dev 44d7b6ee07, exact binary diff SHA-256 aff666c82a9dd82e56d77ed7f70e7eba2a1cf460d18e68372d0db7473c6079dd.

Root cause confirmed from source exactly as reported: after replay flips logicalSessionIdTrusted=true, #leaseAllows requires an authorized recovery lease and a non-expired topic host lease, while renewActiveTopicLeases only renewed sessions that already passed that same gate — so the 20s HEARTBEAT_TTL_MS expiry was permanent and every later frame died pre-send with trusted attachment lease is stale.

Your suggested mechanism was correct but incomplete: the incident's persisted record was authorityState: "disconnect_grace", which TTL-ignoring renewal alone would still reject. The implemented invariant mirrors TopicRegistry.acquireLease admission for a live owner — expired-but-owned active or owned resume inside the disconnect-grace window — so the re-arm path is exactly as strict as the registry mutation itself. Foreign owner, replaced socket, malformed/quarantined/archived/inactive bindings remain denied (pinned by tests).

Evidence: 6-case discriminating regression suite (3 cases fail with the fix reverted), 266 focused Telegram tests green at this head, Telegram daemon generation guard v51 verified (169→170), types/lint/gates clean. Independent exact-head review by @probepark @snowykr has been requested on the PR; merge is blocked on that approval by the repo's exact-head PR contract (current verdict needs-human).

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Status update — fix is complete and verified at PR #4648 head ffd3a20de398264dc5c25499a49c8dab977e31f4 (rebased onto live dev 7265a61c8e; exact three-dot binary diff SHA-256 ec6bb8bf0b04d1a7305e41a2d2dfcd8fc5bbfedfcb4a94ca751406e55eb2fbc6).

Exact-head CI (run 32093149158): every product job green, including the dedicated notifications-telegram-topic-lease-renewal.test.ts regression suite (6/6; 3 cases fail with the fix reverted — post-TTL publish, heartbeat re-arm, grace resume — while foreign-owner / replaced-socket / archive-fenced cases stay denied), plus Telegram daemon generation guard (169→170) and Windows Telegram daemon safety.

Remaining gate: the repository's exact-head PR contract requires an independent (non-author) APPROVED review before merge-approved; the PR verdict is truthfully needs-human with reviewer-id:pending and @probepark @snowykr have the request. This issue closes automatically when #4648 merges.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Resolved and merged: PR #4648 landed on dev as merge commit d519c3eb767dc255b889e9529f6ca216d26b1c96. Exact-head product validation, Telegram lease regressions, Windows safety, and virtual integration completed successfully before merge; current dev CI for that merge is still running/queued and is tracked separately. The issue-level defect is terminally fixed by the merged change, so this issue is now closing.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]