fix(slack): ignore app_mention re-fires from message edits

[richardsolomou]

Problem

Editing a Slack message that mentions @PostHog (the coding-agent bot) created a second task in parallel with the original. The user expects one task per intent; the edit should not spawn another.

Slack re-fires app_mention with a fresh event_id whenever a previously-mentioning message is edited. The dispatcher in products/slack_app/backend/api.py derives the Temporal workflow id from event_id, so the edit's workflow id differs from the original's and Temporal's USE_EXISTING policy does not deduplicate it. Both workflows run forward_posthog_code_followup_activity, find no SlackThreadTaskMapping yet (the original workflow hasn't written it), and each fall through to create_posthog_code_task_for_repo_activity — producing two Task rows for the same intent.

Changes

• Add _is_app_mention_edit(event) helper that returns true when Slack marks the event as an edit (event.edited set, or subtype: "message_changed").
• In route_posthog_code_event_to_relevant_region, short-circuit app_mention events that match before any workflow is started, log posthog_code_event_edit_ignored, and return ROUTE_HANDLED_LOCALLY.

Rejected alternative: re-keying the Temporal workflow id on (slack_team_id, channel, thread_ts) so USE_EXISTING would dedupe the edit automatically. This would also have absorbed legitimate same-thread follow-ups into the running workflow, which is already what forward_posthog_code_followup_activity is designed to handle as a separate workflow invocation — so re-keying would have changed semantics beyond fixing the bug.

Not rejected but worth noting: Slack also emits app_mention when a user edits a previously-non-mentioning message to add the bot mention. In that case event.edited is still set, so this guard will drop those too. That tradeoff matches the user's expectation as described and avoids the racier "check SlackThreadTaskMapping before dispatch" path, which is subject to the same race that produced the bug.

How did you test this code?

I'm Claude / PostHog Code. The Claude Code for web environment did not have a working Python 3.12.12 toolchain available (only 3.12.13 builds are published), so I did not run the Django test suite locally. Verified instead:

• ruff check and ruff format --check pass on both touched files.
• ast.parse confirms the test file and api.py are syntactically valid.
• The two added parameterized cases (edited_field, message_changed_subtype) cover both Slack markers and assert that sync_connect / asyncio.run are never invoked when the edit guard fires.

CI is the source of truth for the test run.

Publish to changelog?

no

🤖 Agent context

Authored by PostHog Code (Claude Opus 4.7). The user reported the duplicate-task behavior, and I traced it through products/slack_app/backend/api.py → posthog/temporal/ai/posthog_code_slack_mention.py. The investigation considered three fixes:

1. Drop edits at dispatch (this PR).
2. Re-key Temporal workflow id on (team, channel, thread_ts) — rejected as overly broad, would change follow-up semantics.
3. Pre-dispatch SlackThreadTaskMapping lookup — rejected because it doesn't fix the race (the original workflow may not have written the mapping by the time the edit arrives), and would break legitimate same-thread follow-ups which intentionally start a new workflow.

Reviewers: please confirm the assumption that Slack does not fire app_mention for edits-that-newly-add-a-mention without event.edited being set (matches Slack's documented behavior and matches the user-reported scenario, but I have not verified against a live Slack webhook capture).

---

Created with PostHog Code

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix(slack): ignore app_mention re-fires ..." | Re-trigger Greptile}

[github-actions]

ClickHouse migration SQL per cloud environment

No ClickHouse migrations changed in this PR.

[VojtechBartos]

Thanks 👍

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-05-27 07:53 UTC	Run
prod-us	✅ Deployed	2026-05-27 08:04 UTC	Run
prod-eu	✅ Deployed	2026-05-27 08:12 UTC	Run