Someone reported on 2026-07-31 that Slack banners arrived late, for "a workspace I was not in". I no longer have a thread to reply on, so this is a tracking issue: if you see this, a timeline would close it.
What was probably wrong, and is fixed
A service with no live web view posts no banners at all. Notifications reach Chorus through a handler injected into the page, and only the active space was ever preloaded, so a chat service sitting in another space was silent until you went to it. "A workspace I was not in" fits that exactly.
Chat services in every space are preloaded now, capped at five. That shipped in 1.5.18, so it is in the version you have.
Why it is not closed
One path is still uncovered. A notification raised inside a service worker — the push path — runs where no page script can reach, so if Slack delivers to you that way, the fix does nothing for it. That is a different bug with a different fix, and I cannot tell the two apart without a timeline.
What would help
If Slack banners still arrive late on 1.5.18 or later:
- When the message was sent, and when the banner arrived. Rough minutes are fine.
- Whether that Slack service was the one on screen, in another space, or hibernated.
- Its hibernation setting, from the service's own settings: follow the global setting, never, immediately, or after a delay.
- Whether it is a second Slack service in Chorus, or a second workspace inside one Slack service already there. Those are different bugs. One Slack web client only runs the workspace it has loaded.
A "no longer happens on 1.5.18" is just as useful, and closes this.
One caveat for anyone testing on a machine that has run development builds: notification authorization for Chorus can get wedged to denied, which looks exactly like lateness and is really a permission state. Worth checking in System Settings first.
Someone reported on 2026-07-31 that Slack banners arrived late, for "a workspace I was not in". I no longer have a thread to reply on, so this is a tracking issue: if you see this, a timeline would close it.
What was probably wrong, and is fixed
A service with no live web view posts no banners at all. Notifications reach Chorus through a handler injected into the page, and only the active space was ever preloaded, so a chat service sitting in another space was silent until you went to it. "A workspace I was not in" fits that exactly.
Chat services in every space are preloaded now, capped at five. That shipped in 1.5.18, so it is in the version you have.
Why it is not closed
One path is still uncovered. A notification raised inside a service worker — the push path — runs where no page script can reach, so if Slack delivers to you that way, the fix does nothing for it. That is a different bug with a different fix, and I cannot tell the two apart without a timeline.
What would help
If Slack banners still arrive late on 1.5.18 or later:
A "no longer happens on 1.5.18" is just as useful, and closes this.
One caveat for anyone testing on a machine that has run development builds: notification authorization for Chorus can get wedged to denied, which looks exactly like lateness and is really a permission state. Worth checking in System Settings first.