Notifications are not sent sometimes

[s0len]

Description

I've used Claude with Fable 5 to debug this and found that MEDIA_AVAILABLE is never sent on PostgreSQL. Availability re-check runs while the media-save transaction is still open (race on ≤3.3.x, deterministic since v3.4.0).

When a scan flips a requested movie from PROCESSING to AVAILABLE on a PostgreSQL
deployment, the MEDIA_AVAILABLE notification is silently dropped. The request is still
marked COMPLETED and the media AVAILABLE, so everything looks processed, only the
notification is lost, with zero log output. On v3.4.0+ this happens on every
scanner-driven availability transition; on ≤3.3.x it was intermittent. SQLite is
unaffected, which I believe is why this has been hard to reproduce upstream (#1771 was
this same symptom on PostgreSQL, the thread even asks the reporter for their
PostgreSQL version).

I'm running a fix in production: afterUpdate queues the work on queryRunner.data
and a new MediaSubscriber.afterTransactionCommit flushes it after the real COMMIT
(guarded with isTransactionActive, since savepoint releases broadcast the same
event). The deferred run sees the committed AVAILABLE row and the notification
dispatches; awaits are preserved, and a rolled-back save discards its queued work.
Verified over multiple full-scan runs: every transition of a requested title notifies,
routine updates no-op cleanly. Happy to open a PR if this approach sounds right.

(For transparency: I reported this symptom before in #3213 with a diagnosis that was
wrong — the rebuttal there was correct about those mechanisms. This report is a
different mechanism, verified line-by-line, with the deterministic repro below.)

Version

3.4.1

Steps to Reproduce

1. Run seerr v3.4.1 with DB_TYPE=postgres, Plex + Radarr configured, Discord (or any)
   agent enabled with the "Media Available" type, LOG_LEVEL=debug.
2. Pick any movie that is already AVAILABLE in seerr and has a COMPLETED request.
3. In the database, reset it to the pre-scan state:
   UPDATE media SET status = 3 WHERE id = <mediaId>;
UPDATE media_request SET status = 2 WHERE id = <requestId>;
4. Run the "Plex Full Library Scan" job from Settings → Jobs.
5. The scan logs "Media for <title> exists. Changes were detected and the title will
   be updated.", the media returns to AVAILABLE and the request to COMPLETED — but no
   "Sending notification(s) for MEDIA_AVAILABLE" line ever appears and no notification
   is sent. Repeat as often as you like; on PostgreSQL it drops every time on v3.4.x.
   The same steps on SQLite produce the notification.

Screenshots

No response

Logs

2026-08-08T11:30:35Z [info][Notifications]: Sending notification(s) for MEDIA_AUTO_APPROVED {"subject":"Lawless (2012)"}
2026-08-08T11:30:35Z [debug][Notifications]: Sending Discord notification {"type":"MEDIA_AUTO_APPROVED","subject":"Lawless (2012)"}
... (Radarr downloads and imports; Plex picks the file up at its nightly library scan) ...
2026-08-08T23:05:00Z [info][Plex Scan]: Media for Lawless exists. Changes were detected and the title will be updated.
2026-08-08T23:05:04Z [info][Plex Scan]: Beginning to process recently added for library: Animeserier
    <-- no MEDIA_AVAILABLE, no error, nothing — the request is COMPLETED and the media AVAILABLE in the DB

With the after-commit fix applied, the same transition:

2026-08-10T19:30:06Z [debug][Media]: Deferred related request update until transaction commit {"mediaId":3949}
2026-08-10T19:30:06Z [info][Notifications]: Sending notification(s) for MEDIA_AVAILABLE {"subject":"Lawless (2012)"}
2026-08-10T19:30:06Z [debug][Notifications]: Sending Discord notification {"type":"MEDIA_AVAILABLE","subject":"Lawless (2012)"}

Platform

desktop

Database

PostgreSQL

Device

N/A

Operating System

Kubernetes (Talos)

Browser

N/A

Additional Context

No response

Search Existing Issues

• Yes, I have searched existing issues.

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[github-actions]

Possible duplicate detected

This issue may be a duplicate of the following (detected via semantic similarity + LLM review):

• MEDIA_AVAILABLE notifications silently dropped for fast-fulfilled requests (v3.3.0) #3213 (85% match) — MEDIA_AVAILABLE notifications silently dropped for fast-fulfilled requests (v3.3.0)
• Library scans (on some setups) deadlock the Postgres connection pool (app unresponsive, no errors, restart required) #3365 (80% match) — Library scans (on some setups) deadlock the Postgres connection pool (app unresponsive, no errors, restart required)
• Radarr Scan permanently exhausts the Postgres connection pool on 3.4.x (regression from 3.3.0) #3363 (68% match) — Radarr Scan permanently exhausts the Postgres connection pool on 3.4.x (regression from 3.3.0)

A maintainer will review this. If this is not a duplicate, no action is needed.

[s0len]

Regarding the duplicate flags: #3213 was mine and the diagnosis in it was wrong, so nothing to salvage there, this issue supersedes it.

#3365 however looks like the same root cause as this one, just showing up as a different symptom. The pattern described there (the MediaSubscriber helpers being awaited inside the media-save transaction since #3223, while querying through the global getRepository which needs a second pool connection) can end two ways depending on how many saves qualify at the same time:

• enough concurrent status transitions to eat the whole pool -> everything blocks, which is Library scans (on some setups) deadlock the Postgres connection pool (app unresponsive, no errors, restart required) #3365
• fewer than that -> the second connection is acquired just fine, but it reads the DB state from before the still-open transaction, so the availability check in notifyAvailableMovie/Series sees the old PROCESSING status and returns without sending anything. That's this issue.

My setup is the second case, scans usually only flip one or two requested titles at a time, so I've never had a hang, but 100% of MEDIA_AVAILABLE has been dropped since 3.4.x (and it was an occasional race before that).

Bringing it up because it matters for the fix in #3365: a bigger pool or an acquire timeout would solve the hang but leave this broken. Going through event.manager instead of the global repo, or deferring the subscriber work until after the commit, should fix both. I've been running the after-commit variant patched into my instance since yesterday and every transition notifies again.

[dasbaum-ch]

Same for me with DB_TYPE=postgres and Jellyfin. Since v3.4.0, I haven't been receiving email notifications when something is available. Only the MEDIA_AUTO_APPROVED mails are working.

Testet with Spider-Man: Homecoming, see logs.

seerr-2026-08-11.log

[fallenbagel]

This is the same root cause as the connection pool deadlock we've been tracking, just a different symptom of it.
#3365

Both come from #3223: the MediaSubscriber helpers became awaited inside the transaction TypeORM opens for the media save, but they still go through the global getRepository(), so the request save runs on a second connection. MediaRequestSubscriber.afterUpdate then hands that second connection's manager to the availability check:

seerr/server/subscriber/MediaRequestSubscriber.ts

Lines 49 to 56 in dea5960

	// Get fresh media state using event manager
	let latestMedia: Media | null = null;
	if (event?.manager) {
	latestMedia = await event.manager.findOne(Media, {
	where: { id: entity.media.id },
	});
	}
	if (!latestMedia) {

which reads the committed row as still PROCESSING, because the media save hasn't committed yet and so this returns early and the notification is dropped with no log line:

seerr/server/subscriber/MediaRequestSubscriber.ts

Lines 64 to 68 in dea5960

	if (
	!latestMedia ||
	latestMedia[entity.is4k ? 'status4k' : 'status'] !== MediaStatus.AVAILABLE
	) {
	return;

The other symptom of the same line is the pool wedging during scans where with bundles of 50 against the default pool of 10 and no acquisition timeout, every connection ends up held by a save waiting for a connection that can't be granted.

I have it already fixed in #3366 which routes the subscriber work through event.manager so it rides the save's own connection. That fixes the notification drop as a side effect and the availability check reads the same transaction and sees AVAILABLE and it fixes the deadlock, which your after-commit deferral wouldn't. commitTransaction broadcasts AfterTransactionCommit before the persist executor releases the query runner, so deferred work using the global repositories would still be asking for a second connection while the first is checked out. queryRunner.data is also swapped and restored by nested persist executors, which is exactly the flow here.

And you can already test it with preview:
preview-pgsql-starvation-fix

For context I'm running the preview on postgres myself, on a database I've been carrying since jellyseerr v0.1.0 and migrated when we merged, so it has every bit of accumulated state. Every availability transition has notified, nothing dropped. I have also tested on fresh postgres ans sqlite this preview. Works.

So I will close this as duplicate of that and add this as a related issue. You both should test the preview @s0len @dasbaum-ch

Also, one more thing, I hope you can respect this. Disclosing AI use does not make pasted model output acceptable. Our contributing guide is explicit that PR descriptions and all comments, including issue reports, must be written in your own words:

https://github.com/seerr-team/seerr/blob/develop/CONTRIBUTING.md#expectations-for-ai-assisted-contributions

Disclosure tells us how much scrutiny to apply. It does not exempt a submission from the policy. While I don't want to accuse you, this report reads as model output relayed verbatim rather than your own explanation of what you found, and that is not something we accept, in issues or anywhere else. We are volunteers reviewing this on our own time, and reading a machine's writeup of your problem is not a use of it. If it was, we wouldn't need you in the thread. We can just ask it ourselves.

Use AI as a tool if you want. But please write the report yourself: what you observed, what you tested, what you concluded, in your own words. Reports and comments that read as relayed model output will be closed without review going forward.

Thank you.

[s0len]

Thanks, will try as soon as possible