Skip to content

feat(notifications): notify when focused on a different task#2210

Merged
richardsolomou merged 3 commits into
mainfrom
posthog-code/notify-when-on-different-task
May 19, 2026
Merged

feat(notifications): notify when focused on a different task#2210
richardsolomou merged 3 commits into
mainfrom
posthog-code/notify-when-on-different-task

Conversation

@richardsolomou
Copy link
Copy Markdown
Member

@richardsolomou richardsolomou commented May 19, 2026

Problem

When you're focused on task A inside PostHog Code and task B asks for a permission or finishes its turn, nothing surfaces — the existing notification logic in notifications.ts only fires when the window is unfocused, so a same-window-but-different-task interrupt is silent. Reported as: "no meep when task need input while focus other task, sad".

Changes

Added a shouldNotifyForTask(taskId) helper in apps/code/src/renderer/utils/notifications.ts that consults useNavigationStore for the currently viewed task. Both notifyPromptComplete and notifyPermissionRequest now fire (sound, desktop notification, dock badge, dock bounce) when:

  • the window is unfocused (unchanged), or
  • the window is focused but the user is viewing a different task (new).
Window focused? Viewing same task? Notify?
No Yes (unchanged)
Yes Yes No (unchanged)
Yes No / different task Yes (new)

All existing settings (desktopNotifications, dockBadgeNotifications, dockBounceNotifications, completionSound, completionVolume) still gate the channels — no new preference. Falls back to "don't notify when focused" if taskId is unknown, so callers without a taskId keep their previous behaviour.

Clicking the desktop notification already routes to the right task via TaskLinkServicedeepLink.onOpenTaskuseTaskDeepLinknavigateToTask, so no extra wiring needed there.

How did you test this?

  • pnpm --filter code typecheck — clean
  • pnpm exec biome check apps/code/src/renderer/utils/notifications.ts — clean
  • Traced the click-to-navigate path end-to-end (electron-notifier.ts:25notification/service.ts:38deep-link.ts:27useTaskDeepLink.tsnavigationStore.navigateToTask) to confirm clicking the notification still lands on the originating task.
  • Did not run the app manually in this environment.

Publish to changelog?

no

Previously, permission requests and prompt completions only fired a sound,
desktop notification, and dock badge if the window was unfocused. If the
user was viewing task A in PostHog Code while task B asked for input,
nothing surfaced — they had to manually check the other task.

Now also notify when the window is focused but the user is viewing a
different task (or no task at all). The window-focus path is unchanged.

Generated-By: PostHog Code
Task-Id: b14a2144-3143-4d34-a0e3-2139aabdaed9
@richardsolomou richardsolomou marked this pull request as ready for review May 19, 2026 02:48
@richardsolomou richardsolomou requested a review from a team May 19, 2026 02:48
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 19, 2026

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
apps/code/src/renderer/utils/notifications.ts:16-23
**Missing automated tests for `shouldNotifyForTask`**

The new helper has three distinct, clearly-testable branches (unfocused → always notify; focused + no taskId → never notify; focused + taskId → compare with viewed task), yet no test file exists for `notifications.ts`. Given the vitest infrastructure already present (see `navigationStore.test.ts` for the mocking pattern), and simplicity rule #1 ("Passes all the tests"), these branches should have parameterised unit tests covering at minimum: window unfocused, window focused with matching taskId, window focused with different taskId, and window focused with no taskId.

Reviews (1): Last reviewed commit: "feat(notifications): notify when focused..." | Re-trigger Greptile

Comment thread apps/code/src/renderer/utils/notifications.ts
@richardsolomou richardsolomou added the Create Release This will trigger a new release label May 19, 2026
Adds unit tests for the new shouldNotifyForTask gate via the
notifyPermissionRequest / notifyPromptComplete public surface:

- unfocused → notifies regardless of task
- focused on same task → suppressed
- focused on different task → notifies
- focused, non-task-detail view → notifies
- focused, no taskId supplied → suppressed
- end_turn filter still gates notifyPromptComplete

Generated-By: PostHog Code
Task-Id: b14a2144-3143-4d34-a0e3-2139aabdaed9
Copy link
Copy Markdown
Contributor

@jonathanlab jonathanlab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Comment thread apps/code/src/renderer/utils/notifications.test.ts
Per review feedback, switch the six gating cases and the stop-reason
filter to it.each tables so adding a new branch is a one-line change.

Generated-By: PostHog Code
Task-Id: b14a2144-3143-4d34-a0e3-2139aabdaed9
@richardsolomou richardsolomou enabled auto-merge (squash) May 19, 2026 16:41
@richardsolomou richardsolomou merged commit b8524c4 into main May 19, 2026
15 checks passed
@richardsolomou richardsolomou deleted the posthog-code/notify-when-on-different-task branch May 19, 2026 16:51
richardsolomou added a commit that referenced this pull request May 20, 2026
Clicking a desktop notification was supposed to switch the app to the
task it was about (via TaskLinkService → deepLink.onOpenTask →
useTaskDeepLink → navigateToTask), but the JS click listener was never
firing. On macOS the OS still raised the app on click, so it looked
like "focus works but navigation doesn't" — which is exactly how this
surfaced after PR #2210 started firing notifications for other tasks
while the app was already focused.

Root cause: ElectronNotifier.notify() created `new Notification(...)`
in a local variable and let it fall out of scope after `.show()`. V8
could GC the JS wrapper (and the `click` listener with it) before the
user clicked.

Fix: hold a reference in an instance Set until the notification is
clicked or closed, then release it. No behaviour change beyond keeping
the wrapper alive long enough for its events to reach JS.

Generated-By: PostHog Code
Task-Id: ed71008c-f6e9-4cb8-ad76-006037bcce5b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Create Release This will trigger a new release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants