fix(tasks): don't flash the Slack icon on newly created tasks

[pauldambra]

Problem

A newly created task in posthog/code would sometimes flash the Slack icon while it was still loading, even though it wasn't a Slack-triggered task. It self-corrected a moment later.

Root cause: useCreateTask.invalidateTasks optimistically inserts the new task into every task-list cache via setQueriesData({ queryKey: taskKeys.lists() }, ...), and taskKeys.lists() prefix-matches the slack-origin list too (useSlackTasks). Because /tasks/summaries/ omits origin_product, the sidebar infers a task's Slack origin purely by id membership in that slack list (buildSidebarData.ts). So the freshly created, non-slack task landed in slackTaskIds and rendered the Slack icon until useSlackTasks refetched from the server and dropped it.

Changes

Scope the optimistic insert to list caches that aren't filtered by origin_product, using a predicate that skips any list query whose filter has originProduct set. The slack-origin cache stays clean, so the new task never transiently shows the Slack icon.

How did you test this?

• Added a regression test in useTaskCrudMutations.test.tsx asserting invalidateTasks seeds the plain list but not the slack-origin list. pnpm exec vitest run useTaskCrudMutations.test.tsx → 3 passed.
• biome lint clean on both changed files.
• pnpm --filter @posthog/ui typecheck passes.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code from a Slack thread

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 6185233.}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/tasks/useTaskCrudMutations.test.tsx:96-117
**Prefer parameterised tests**

The single `it` block verifies the slack case, but the predicate `!filters?.originProduct` is meant to exclude *any* origin-product-filtered cache, not just slack. A parameterised test would prove the fix holds for other origin products (e.g. `"linear"`, `"github"`) and that caches filtered only by non-`originProduct` fields (e.g. `{ repository: "my-repo" }`) are still optimistically seeded as intended. Testing only the slack example leaves the more general contract implicit.

_{Reviews (1): Last reviewed commit: "fix(tasks): don't seed the slack-origin ..." | Re-trigger Greptile}

[greptile-apps]

Prefer parameterised tests

The single it block verifies the slack case, but the predicate !filters?.originProduct is meant to exclude any origin-product-filtered cache, not just slack. A parameterised test would prove the fix holds for other origin products (e.g. "linear", "github") and that caches filtered only by non-originProduct fields (e.g. { repository: "my-repo" }) are still optimistically seeded as intended. Testing only the slack example leaves the more general contract implicit.

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/ui/src/features/tasks/useTaskCrudMutations.test.tsx
Line: 96-117

Comment:
**Prefer parameterised tests**

The single `it` block verifies the slack case, but the predicate `!filters?.originProduct` is meant to exclude *any* origin-product-filtered cache, not just slack. A parameterised test would prove the fix holds for other origin products (e.g. `"linear"`, `"github"`) and that caches filtered only by non-`originProduct` fields (e.g. `{ repository: "my-repo" }`) are still optimistically seeded as intended. Testing only the slack example leaves the more general contract implicit.

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[pauldambra]

Note

🤖 Automated comment by QA Swarm — not written by a human

Multi-perspective review: paul-reviewer, xp-reviewer, security-audit (qa-team skipped — not present in this repo)

Verdict: 💬 APPROVE WITH NITS

Correct, well-targeted fix for a real, subtle bug. No correctness or security issues. One convergent design nit worth a look; the rest are optional.

Convergence (highest confidence — flagged independently by paul + xp)

• useTaskCrudMutations.ts — query.queryKey[2] positional index + hand-written { originProduct?: string } type is fragile structural coupling. The key-shape knowledge (taskKeys.list(filters) ⇒ [...lists(), filters]) lives in taskKeys, but this predicate re-encodes "filters are at slot 2" as a magic index plus a partial restatement of the real filters type. If taskKeys.list ever grows a slot ([...lists(), scope, filters]), the predicate silently matches the wrong slot and the Slack-icon bug quietly regresses — with no test failure. Suggestion: give taskKeys a typed accessor (e.g. taskKeys.filtersOf(queryKey)) so the shape knowledge stays OnceAndOnlyOnce beside where list() defines it. Ironic to guard one bit of positional/id coupling with another. (MEDIUM)

Nits (optional)

• Predicate intent vs comment. Code rejects any origin-filtered list; the comment talks specifically about Slack. Broader is probably safer — just make the invariant the code protects and the comment agree. (LOW)
• Name the rule, not the mechanism. return !filters?.originProduct; reads as "no origin product"; the actual rule is "origin-less lists mirror all new tasks." A named local (isOriginScopedList) or finishing the truncated comment would help. (LOW)
• Test could assert the full contract. Good that both arms are covered (plain seeded → 1, slack not → 0). Worth also asserting the slack list is still invalidated (refetched), so a future refactor can't satisfy the length-0 expectation by dropping the slack list from refetch entirely. A natural it.each table, too. (LOW)

Reviewer summaries

Reviewer	Assessment
👤 paul	tidy fix, comment is genuinely good; only unease is guarding positional coupling with more positional coupling (queryKey[2]) — pull key-reading into taskKeys. not blocking.
📐 xp	right shape (scope the seed, still invalidate all); both test arms covered. one theme: query-key structural knowledge duplicated in the consumer belongs with taskKeys. no must-fix.
🛡 security-audit	no findings — client-side cache seeding of the user's own task into their own local cache, self-corrects on refetch; no trust boundary crossed.

---

Automated by QA Swarm — not a human review

[pauldambra]

Note

🤖 Automated comment by PR Shepherd — not written by a human

Actioned the qa-swarm review in 6185233:

• Convergent MEDIUM (paul + xp): moved the list-key shape knowledge into taskKeys — added a TaskListFilters type and a taskKeys.filtersOf(queryKey) accessor, so the predicate no longer reaches in by positional [2] index or restates a partial filters type.
• Nit (intent vs comment): named the rule isOriginScopedList and finished the comment so it reads "any origin-scoped list," matching the code.
• Nit (test contract): parameterised the seed test across plain / repository / slack lists, and added a test asserting every list is still invalidated (refetched), so the no-seed expectation can't be "fixed" by dropping a list from refetch.

security-audit: no findings. All 6 tests pass, typecheck + biome clean.

[github-actions]

Low-risk UI cache fix: origin-scoped lists are excluded from optimistic seeding while still being invalidated for server reconciliation. The bot comment requesting parameterised tests is outdated — the current diff already uses it.each.