fix(discord): implement messages.statusReactions timing lifecycle#81623
fix(discord): implement messages.statusReactions timing lifecycle#81623umeshchandra-rao wants to merge 1 commit into
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Keep open. Current main and v2026.6.6 still ignore configured Discord terminal status-reaction hold timing, but this PR is conflicting, lacks real Discord proof, and needs to preserve current failed-final delivery error timing before it can merge. Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review. So I’m closing this here because the remaining work is already tracked in the canonical issue. Review detailsBest possible solution: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review. Do we have a high-confidence way to reproduce the issue? Yes, at source level. Current main and v2026.6.6 pass configured timing into the Discord controller but still use hardcoded Is this the best way to solve the issue? No, not as submitted. The direction matches Slack and Telegram, but the branch is stale, must preserve Security review: Security review cleared: The diff only changes Discord runtime timing selection and does not add dependency, workflow, secret, package, or code-execution surface. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 04875efd28ee. |
|
This pull request has been automatically marked as stale due to inactivity. |
|
ClawSweeper applied the proposed close for this PR.
|
Resolves #78431
This PR fixes the issue where Discord status reactions did not properly respect the
doneHoldMsanderrorHoldMslifecycle timings configured incfg.messages.statusReactions.timing. It wires the logic correctly inmessage-handler.process.tsby utilizing the configuration values instead of hardcodingDEFAULT_TIMING.