Problem
Operator-facing Telegram notifications for completion and Refining transitions can fail without a reliable fallback path.
In the affected flow:
- runtime-backed notification delivery can fail
- fallback delivery does not always preserve Telegram topic/thread routing
- some completion/refining notification paths are not awaited before pipeline completion returns
This can leave the issue tracker state updated while the operator-facing Telegram message is missing or misrouted.
Expected behavior
When runtime notification delivery fails, DevClaw should fall back cleanly to CLI delivery.
For Telegram forum/topic routing, the fallback path should preserve the thread identifier so the message goes to the same topic.
Completion and Refining notification paths should also await delivery so the pipeline does not finish before the notification attempt completes.
Observed affected areas
The fix lane that reproduces and addresses this touches notification dispatch and completion pipeline behavior, including:
- runtime-to-CLI fallback behavior in notification sending
- Telegram
messageThreadId / thread-id propagation for fallback routing
- awaited completion/refining notification delivery in pipeline flows
Why this matters
This is operator-visible workflow reliability. A task can transition correctly in GitHub while the corresponding Telegram notification is absent or routed incorrectly, which makes the automation look inconsistent and can hide important state changes.
Problem
Operator-facing Telegram notifications for completion and
Refiningtransitions can fail without a reliable fallback path.In the affected flow:
This can leave the issue tracker state updated while the operator-facing Telegram message is missing or misrouted.
Expected behavior
When runtime notification delivery fails, DevClaw should fall back cleanly to CLI delivery.
For Telegram forum/topic routing, the fallback path should preserve the thread identifier so the message goes to the same topic.
Completion and
Refiningnotification paths should also await delivery so the pipeline does not finish before the notification attempt completes.Observed affected areas
The fix lane that reproduces and addresses this touches notification dispatch and completion pipeline behavior, including:
messageThreadId/ thread-id propagation for fallback routingWhy this matters
This is operator-visible workflow reliability. A task can transition correctly in GitHub while the corresponding Telegram notification is absent or routed incorrectly, which makes the automation look inconsistent and can hide important state changes.