fix(slack-channel-monitor): stop silently dropping trigger messages (search lag, @mention search, thread context, auth cache)

[hboisgibault]

• A human has tested these changes.

---

Why

Four bugs in the slack-channel-monitor poller cause trigger messages to be silently dropped or mishandled. All four were reproduced against a real long-running deployment (polling 1×/min for ~1 month, 33 channels):

1. search.messages index lag: Slack's search index lags the live stream by ~1-2 min, and the script bounded search results by last_poll (which advances every run). A message posted just before a run was often only searchable after last_poll moved past it — dropped forever.
2. @mention triggers unsearchable: search.messages does not index the leading @ of a mention, and a quoted phrase ("openhands") does not match an @openhands mention either. Since the default trigger phrase is an @mention, the search path effectively never matched.
3. Trigger in a thread lost context: search results carry no thread_ts, so a trigger posted as a thread reply looked like a root message and started a fresh conversation instead of continuing the tracked one.
4. Wrong bot identity with user token: auth.test on a user token returns the human owner, so with SLACK_USER_TOKEN every message that human posted was classified as bot output and skipped.

Summary

• Search for trigger messages over a fixed 1-hour window (SEARCH_LOOKBACK_SECONDS) with processed_ts deduplication, instead of bounding by last_poll.
• Search for the bare trigger term (trigger.lstrip("@")); _has_trigger() remains the authoritative exact match.
• Resolve the real thread parent via conversations.replies when a search result has no thread_ts.
• Resolve bot identity from SLACK_BOT_TOKEN when configured (user token auth.test returns the human), and cache the whole auth resolution in _slack_auth_once() (~90% fewer Slack calls on no-trigger runs).
• Minor: INITIAL_LOOKBACK 70 → 600 (safe with dedup), channel_history() gains optional latest param, root-level triggers now include recent channel history in the conversation prompt.

Issue Number

Fixes #542 — filed while operating a production deployment of this skill (needs ready-for-dev triage, see PR comment).

How to Test

1. Create a monitor from this skill against a Slack workspace with both SLACK_BOT_TOKEN and SLACK_USER_TOKEN.
2. Post an @mention trigger in a monitored channel and confirm the conversation opens within 1-2 poll runs even though the message is brand-new (fixes 1 & 2: previously it was often never detected).
3. Post a trigger as a thread reply and confirm the existing tracked conversation is continued rather than a new one being opened (fix 3).
4. Run with only SLACK_USER_TOKEN configured and confirm the human owner's own trigger messages are processed and the bot identity logged is the bot's (fix 4).

This exact code has been running in production for ~3 weeks on the deployment described above.

Video/Screenshots

N/A — behavior is observable in the poller's debug logs (slack_poller_debug.log): search.messages returned N trigger candidate(s), Resolved thread parent …, and the logged Bot user ID now matching the bot rather than the token owner.

Notes

• Fixes 1-4 are behavior-preserving when Slack's search index is up to date and a bot token is configured; they only change the previously-broken paths.
• INITIAL_LOOKBACK widening only adds catch-up fetches on cold start; processed_ts deduplication prevents double-processing.

Co-authored-by: openhands openhands@all-hands.dev

[all-hands-bot]

👋 This PR needs a couple of things fixed before OpenHands can review it:

• the PR description's HUMAN: section needs at least 20 characters describing what you tested, not just the template placeholder

Push an update once this is addressed and this check re-runs automatically.

This is an automated check - no AI was used to generate this comment.

[hboisgibault]

AI note: this PR was created by an AI agent (OpenHands) on behalf of @hboisgibault.

@OpenHands/team — friendly ping for triage: the linked issue #542 cannot receive the ready-for-dev (or bug) label from a contributor account, so the PR description check fails on the linked-issue gate even though the issue body follows the bug-report template. Could a maintainer label the issue (or confirm the gate is waived for this PR)? The four fixes in this PR are all reproduced against a live deployment and detailed in the issue.

[openhands-ai]

I'm on it! hboisgibault can track my progress at all-hands.dev

[hboisgibault]

@OpenHands/team — follow-up from @hboisgibault's comment: I verified the failing check locally, and the only error is the linked-issue gate:

##[error]Linked issue(s) (#542) carry neither `ready-for-dev` nor a pre-rollout creation date.
 Newly referenced issues must meet the readiness criteria before a PR can be opened.

Everything else passes:

• PR template sections — I ran .github/scripts/check_pr_description.py locally against the current PR body → PR description validation passed.

• Issue slack-channel-monitor: search lag / @mention / thread / bot identity fixes #542 readiness — I ran .github/scripts/check_issue_readiness.py --labels bug on the issue body → Issue meets ready-for-dev criteria. The body has a reproducible command (python skills/slack-channel-monitor/scripts/main.py --debug) plus 5 acceptance-criteria checklist items.

• Code — python -m py_compile skills/slack-channel-monitor/scripts/main.py passes,and git diff --check is clean (pr-title checks are green).

The block is purely that a contributor account can't add the bug/ready-for-dev labels (my API call returns Resource not accessible by integration). Could a maintainer add the bug label to #542? The issue-readiness workflow will then auto-add ready-for-dev and re-run this gate (the refresh step re-runs the PR description check for linked PRs). No code change is needed on this PR.

This comment was created by an AI agent (OpenHands) on behalf of @hboisgibault.

[openhands-ai]

I'm on it! hboisgibault can track my progress at all-hands.dev

[openhands-ai]

The comment on PR #541 asked a maintainer-triaged question — I investigated and answered it, posting a comment on the PR.

What I found

The PR's only failing check is "Validate PR description", and the sole error in the latest run is:

Linked issue(s) (#542) carry neither `ready-for-dev` nor a pre-rollout creation date. Newly referenced issues must meet the readiness criteria before a PR can be opened.

Verification I ran (all local, against the current PR head 99c67b3):

1. PR template sections — .github/scripts/check_pr_description.py against the current PR body → PR description validation passed. (Sections Why, Summary, How to Test are all filled in; note the repo's template check does not require a HUMAN: section — the old automated comment about it no longer applies to this check.)
2. Linked issue slack-channel-monitor: search lag / @mention / thread / bot identity fixes #542 readiness — .github/scripts/check_issue_readiness.py --labels bug against the issue body → Issue meets ready-for-dev criteria. The body includes a reproducible command (python skills/slack-channel-monitor/scripts/main.py --debug) and 5 acceptance-criteria checklist items. It only lacks the bug/ready-for-dev labels.
3. Code health — python -m py_compile skills/slack-channel-monitor/scripts/main.py passes; git diff --check is clean; pr-title checks are green.

The blocker

A contributor token cannot add labels to the upstream repo (403 Resource not accessible by integration), so the issue gate can't be satisfied from this side — exactly want the PR comment described.

What I did

Posted a comment on PR #541 (permalink)) confirming there's no code change needed. As soon as a maintainer adds the bug label to #542, the issue-readiness-check workflow auto-applies ready-for-dev and its refresh-linked-pr-gates job re-runs the PR description check — clearing healthe gate without any PR push. (AI-disclosure note included in the comment per policy.)

[openhands-ai]

Investigation complete. Here's my full assessment of the comment addressed to me on PR #541.

What the comment asks

The comment (from @hboisgibault, on behalf of the PR author) is a triage request to @OpenHands/team, not a code-change request: "Could a maintainer add the bug label to #542?" It explicitly concludes: "No code change is needed on this PR."

What I verified (all fresh, just now)

Check	Result
PR head commit	99c67b3 — matches local branch & fork branch (git status clean)
Only failing CI check	Validate PR description (failure); its sole error annotation is exactly the linked-issue gate: Linked issue(s) (#542) carry neither ready-for-dev nor a pre-rollout creation date…
pr-title checks	✅ green (Apply conventional-type label, Lint PR title)
PR description template	✅ .github/scripts/check_pr_description.py → PR description validation passed.
Issue #542 readiness	✅ .github/scripts/check_issue_readiness.py --labels bug → Issue meets ready-for-dev criteria. (body has reproducible command python skills/slack-channel-monitor/scripts/main.py --debug + 5 checklist items)
Code health	✅ python -m py_compile skills/slack-channel-monitor/scripts/main.py passes; git diff --check clean
Labels bug/ready-for-dev exist on repo	✅ both present — no label-creation needed

Why I can't unblock it from this side

My token is the contributor account (hboisgibault, pull-only on OpenHands/extensions). Adding a label via the API returns:

403 Resource not accessible by integration

…exactly what the comment reported. Issue #542 still has no labels as of this check — a maintainer hasn't acted yet.

.

What a maintainer needs to do (and what happens next, automatically)

gh issue edit 542 --repo OpenHands/extensions --add-label bug

Or use the GitHub UI (Issues → #542 → Labels → bug). No other step is needed:

1. The issue-readiness-check workflow fires on the labeled event → evaluates slack-channel-monitor: search lag / @mention / thread / bot identity fixes #542 with the bug label → the body already meets the criteria → auto-adds ready-for-dev.高
2. That ready-for-dev labeled event triggers the refresh-linked-pr-gates job → re-runs Validate PR description for PR fix(slack-channel-monitor): stop silently dropping trigger messages (search lag, @mention search, thread context, auth cache) #541 → with the gate satisfied, the check goes green. No PR push required.

What I did / did not do

• No code changes — per the comment's conclusion, and because the PR's failing check is purely an issue-labeling gate, not a code defect.

• No PR comment posted — the PR thread already contains the complete answer from this agent's previous run (comment 5571887527 at 14:12:27Z: same verification, same conclusion, permalink to the exact unblock path）. Posting again would be redundant noise on a public thread. I'm happy to post a follow-up if you'd prefer one.

Bottom line: The PR is code-complete and ready; the only thing standing between it and a green check is a maintainer adding the bug label to issue #542.