Live WebSocket notifications only reach clients on the writing pod #20

New Issue

2026-09-13T13:33:16+10:00

unkin-agent commented

2026-09-13 13:33:16 +10:00

Context: multi-replica stateless deployment (two 2-replica apps, cheeztv and fafflix, each one PostgreSQL plus valkey, no sticky sessions). Not a 12.0 regression — live in the deployed build. Tracking: #12.

Problem

Emby.Server.Implementations/EntryPoints/LibraryChangedNotifier.cs:80-82 — and the user-data change notifier alongside it — broadcast only to WebSocket connections held by the pod that performed the write.

Clients connected to any other pod keep a stale UI until they poll or the user refreshes: newly added episodes do not appear, played marks and resume positions do not update live. The database is correct; only the push is missing.

Proposal

Falls out of #16: once a session directory and cross-pod bus exist, publish these notifications onto the bus and let each pod deliver to its own local connections. No separate mechanism is needed.

Depends on #16.

Acceptance

Two independently constructed instances sharing one valkey and one real PostgreSQL: a library change applied via A delivers a WebSocket notification to a client connected to B.
Same for a user-data change notification.
Tests use PostgreSqlTestServer in tests/Jellyfin.Server.Tests and run in the postgres-migration-chain Woodpecker step (JELLYFIN_TEST_POSTGRES). In-memory providers have hidden different semantics and are how three bugs reached production.

Context: multi-replica stateless deployment (two 2-replica apps, `cheeztv` and `fafflix`, each one PostgreSQL plus valkey, no sticky sessions). Not a 12.0 regression — live in the deployed build. Tracking: #12. ## Problem `Emby.Server.Implementations/EntryPoints/LibraryChangedNotifier.cs:80-82` — and the user-data change notifier alongside it — broadcast only to WebSocket connections held by the pod that performed the write. Clients connected to any other pod keep a stale UI until they poll or the user refreshes: newly added episodes do not appear, played marks and resume positions do not update live. The database is correct; only the push is missing. ## Proposal Falls out of #16: once a session directory and cross-pod bus exist, publish these notifications onto the bus and let each pod deliver to its own local connections. No separate mechanism is needed. Depends on #16. ## Acceptance - Two independently constructed instances sharing one valkey and one real PostgreSQL: a library change applied via A delivers a WebSocket notification to a client connected to B. - Same for a user-data change notification. - Tests use `PostgreSqlTestServer` in `tests/Jellyfin.Server.Tests` and run in the `postgres-migration-chain` Woodpecker step (`JELLYFIN_TEST_POSTGRES`). In-memory providers have hidden different semantics and are how three bugs reached production.

unkin-agent referenced this issue

2026-09-13 13:33:42 +10:00

No shared session directory: cross-pod session operations fail #16

unkin-agent referenced this issue

2026-09-13 13:33:42 +10:00

HA: in-process single-instance assumptions under multi-replica deployment (tracking) #12

unkin-agent referenced this issue

2026-09-24 22:49:01 +10:00

feat(session): share the session directory between instances #33

Sign in to join this conversation.