ExcludedAlbums causes /api/asset to deadlock silently in v1.0.34 (cache poisoning wedges all clients); v1.0.33 crashes at the same code path

[afonsolaw]

Version

v1.0.34.0

Deployment Method

Docker

Description

1. Immich v3 server (v3.0.1) with a large library (~96,700 assets); create an album with a few thousand assets (~2,750 in my case).
2. Run ImmichFrame v1.0.34.0 (Docker) with ExcludedAlbums: "". Also set in my config: People (3 person UUIDs), Interval, ShowClock - but removing ExcludedAlbums alone resolves it, and People alone works fine.
3. From a fresh client: curl -m 120 http://:8080/api/asset -> no response ever; curl exits with HTTP 000 at the timeout.
4. Container log shows the startup pool build completing normally (paginated POST /api/search/metadata, all 200s), then nothing: the hung /api/asset request produces ZERO outbound calls and ZERO errors.
5. Open the web UI from 1-2 more devices -> previously-working clients stop advancing too (their next asset request queues behind the poisoned cache entry). Web UI shows the "Looks like your immich-server is offline or you misconfigured immichFrame" page even though the server is healthy.
6. Remove ExcludedAlbums, recreate the container -> /api/asset returns within seconds and all clients work.

Reproduced identically on linux/amd64 (Synology DSM) and linux/arm64 (macOS/Colima), one via direct container network, one via HTTPS reverse proxy - not network- or architecture-specific.

Reproduction

Immich v3 server with a large library; create an album with a few thousand assets.
Run ImmichFrame v1.0.34.0 with ExcludedAlbums: "" (a People filter appears not to matter — see note above).
curl -m 120 http://:8080/api/asset from a fresh client → no response, curl exits with HTTP 000 at the timeout.
Container log shows the startup pool build completing normally (paginated POST /api/search/metadata, all 200s), then nothing: the hung /api/asset request produces zero outbound calls and zero errors.
Open the web UI from 1-2 more devices → previously-working clients stop advancing too (their next asset request queues behind the poisoned cache entry). Web UI shows the "Looks like your immich-server is offline or you misconfigured immichFrame" page even though the server is healthy.
Remove ExcludedAlbums, recreate the container → /api/asset returns within seconds and all clients work.

Expectations

/api/asset either returns assets with the excluded album applied, or fails fast with a logged error. A failed/hung excluded-album fetch should not be cached (GetOrCreateAsync) in a state that permanently blocks all clients until container restart.

Evidence the excluded-album fetch is the failing path: pinning v1.0.33.0 against the same Immich v3.0.1 crashes IMMEDIATELY (HTTP 500) at the identical call site - AssetHelper.GetExcludedAlbumAssets -> CachingApiAssetsPool.AllAssets -> GetOrCreateAsync - with 'Error converting value "owner" to type AlbumUserRole' (expected pre-v3 incompatibility, but it pins the operation: old code THROWS where v1.0.34 HANGS). Full stack traces available on request.

Configuration

Docker compose environment (docker-compose.yml, not Settings.xml):

services:
  immichframe:
    container_name: immichframe
    image: ghcr.io/immichframe/immichframe:latest   # = v1.0.34.0
    restart: on-failure
    ports:
      - "8080:8080"
    environment:
      TZ: "America/New_York"
      ImmichServerUrl: "http://immich_server:2283"   # also reproduced via https reverse proxy
      ApiKey: "REDACTED"
      Interval: "10"
      People: "UUID1,UUID2,UUID3"
      ExcludedAlbums: "ALBUM_UUID"    # <- removing only this line fixes it
      ShowClock: "true"
      ClockFormat: "hh:mm"

Logs

=== v1.0.34.0: pool build completes, then /api/asset hangs with NOTHING logged ===
26-07-05 13:39:01 info: ...ImmichApiAccountClient.ClientHandler[101] Received HTTP response headers after 126.276ms - 200
[... ~30 more paginated POST /api/search/metadata calls, all 200, 300-600ms each ...]
26-07-05 13:39:12 info: ...ImmichApiAccountClient.LogicalHandler[101] End processing HTTP request after 648.6501ms - 200
[log ends - curl -m 120 http://localhost:8080/api/asset from this point = HTTP 000 at 120.001s, zero new log lines, zero outbound calls]

=== v1.0.33.0 against the same server: instant HTTP 500 pinning the code path ===
26-07-05 13:57:59 fail: Microsoft.AspNetCore.Server.Kestrel[13] An unhandled exception was thrown by the application.
ImmichFrame.Core.Api.ApiException: Could not deserialize the response body stream as ImmichFrame.Core.Api.AlbumResponseDto.
 ---> Newtonsoft.Json.JsonSerializationException: Error converting value "owner" to type 'ImmichFrame.Core.Api.AlbumUserRole'. Path 'albumUsers[0].role'
   at ImmichFrame.Core.Api.ImmichApi.GetAlbumInfoAsync(Guid id, String key, Nullable`1 withoutAssets, CancellationToken cancellationToken)
   at ImmichFrame.Core.Helpers.AssetHelper.GetExcludedAlbumAssets(ImmichApi immichApi, IAccountSettings accountSettings, CancellationToken ct) in AssetHelper.cs:line 15
   at Microsoft.Extensions.Caching.Memory.CacheExtensions.GetOrCreateAsync[TItem](IMemoryCache cache, Object key, Func`2 factory, MemoryCacheEntryOptions createOptions)
   at ImmichFrame.Core.Logic.Pool.CachingApiAssetsPool.AllAssets(CancellationToken ct) in CachingApiAssetsPool.cs:line 23
   at ImmichFrame.Core.Logic.Pool.CachingApiAssetsPool.GetAssetCount(CancellationToken ct) in CachingApiAssetsPool.cs:line 13
   at ImmichFrame.Core.Logic.AccountSelection.TotalAccountImagesSelectionStrategy.GetWeights(IList`1 accounts)
   at ImmichFrame.WebApi.Controllers.AssetController.GetAssets(String

Pre-Submission Checklist

• This is a bug report and not a feature request

• I have provided all of the required information to reproduce the bug (config, logs, etc.)

• I have checked for related issues and checked the documentation

[3rob3]

Just to clarify, you mention multiple times setting ExcludedAlbums: "", but your config appears you are setting it with a UUID. Are you setting this, and is it the album with a few thousand assets?

[afonsolaw]

Yes, confirming: ExcludedAlbums is set to a single real album UUID (I redacted it as "ALBUM_UUID" in the config block - apologies if a redaction elsewhere read as an empty string). And yes, it's the album with a few thousand assets (~2,750).

To restate the key behavior: with that one line present, the first /api/asset call from any new client identifier hangs indefinitely (curl exits HTTP 000 at any timeout) with zero outbound HTTP calls and zero exceptions logged after the initial pool build completes, and subsequent clients then wedge behind it. Deleting only that line and recreating the container makes everything work within seconds. People filter (3 person UUIDs) is set in both cases.

Happy to run a debug build or capture anything else useful - reproducible at will on both amd64 and arm64 here.

[3rob3]

@JW-CH It seems like the OpenAPI spec generator didn't run correctly?

[JW-CH]

@JW-CH It seems like the OpenAPI spec generator didn't run correctly?

Pretty sure its correct. I cannot reproduce this in my instance(s). All running immich >= 3.x

[3rob3]

Neither can I. I just set an ExcludedAlbum and it was fine.

[afonsolaw]

Ok, I owe you both a correction - I deleted my earlier comments because I had part of it wrong. It's not a deadlock, it's a massive slowdown that only happens when People and ExcludedAlbums are set together. My original "hang" was just my curl timeout being shorter than the actual response time.
Here are clean numbers, same album, same server (immich 3.0.1), v1.0.34, measured back to back:
Either filter alone (People with 3 person UUIDs, or ExcludedAlbums with a ~2750 asset album): /api/asset returns in under 3 seconds on both of my boxes.
Both set together, arm64 mac mini M4 Pro: 47.7s for the first call, 33.7s for the second. So it's grinding on every request, not building something once and caching it.
Both set together, amd64 Synology: 398.6s first call, 391.2s second call. Six and a half minutes per photo, every photo.
Library is ~96.7k assets. So whatever happens when the People pool has to subtract an excluded album looks like it blows up somewhere around O(library x something), and how bad it feels just depends on your CPU. On a fast box it's 30-50 second fetches (still unusable for a 10 second slideshow), on a slow one it might as well be hung - and that also explains why a couple of browser tabs stacking their own 6-minute requests looked like the whole thing wedged.
Probably also why you two couldn't repro - if you tested on decent hardware with a smaller library, the combo might have just felt a bit slow rather than broken.
Thanks everyone for your comments.

[3rob3]

FYI, v1.0.35 was released last week. Doubt it would effect this but worth updating regardless.

[JW-CH]

Ok, I owe you both a correction - I deleted my earlier comments because I had part of it wrong. It's not a deadlock, it's a massive slowdown that only happens when People and ExcludedAlbums are set together. My original "hang" was just my curl timeout being shorter than the actual response time. Here are clean numbers, same album, same server (immich 3.0.1), v1.0.34, measured back to back: Either filter alone (People with 3 person UUIDs, or ExcludedAlbums with a ~2750 asset album): /api/asset returns in under 3 seconds on both of my boxes. Both set together, arm64 mac mini M4 Pro: 47.7s for the first call, 33.7s for the second. So it's grinding on every request, not building something once and caching it. Both set together, amd64 Synology: 398.6s first call, 391.2s second call. Six and a half minutes per photo, every photo. Library is ~96.7k assets. So whatever happens when the People pool has to subtract an excluded album looks like it blows up somewhere around O(library x something), and how bad it feels just depends on your CPU. On a fast box it's 30-50 second fetches (still unusable for a 10 second slideshow), on a slow one it might as well be hung - and that also explains why a couple of browser tabs stacking their own 6-minute requests looked like the whole thing wedged. Probably also why you two couldn't repro - if you tested on decent hardware with a smaller library, the combo might have just felt a bit slow rather than broken. Thanks everyone for your comments.

Good insights, and yes, this filtering is done manually because the immich api does not offer this functionality. My issue with this explaination is, that you had Newtonsoft.Json.JsonSerializationException: Error converting value "owner" to type 'ImmichFrame.Core.Api.AlbumUserRole'. Path 'albumUsers[0].role' in your log, which makes no sense to me.

[taysuus]

Are people still getting roles back as ints also on 3.0? Could a PR be made for ImmichFrame to accept both? It just seems a bit silly now, I have 3 frames and none of them are working because this one field that isn't even relevant is breaking the whole thing

[JW-CH]

Are people still getting roles back as ints also on 3.0? Could a PR be made for ImmichFrame to accept both? It just seems a bit silly now, I have 3 frames and none of them are working because this one field that isn't even relevant is breaking the whole thing

Much more changed on the API-Side of immich, so it's not just 'this one field'. Also the explaination afonsolaw provided does not explain the log they are getting.

[3rob3]

@taysuus I am not clear on what your issue is, or what you are suggesting. Are you on Immich v3+ and latest Frame?

[Poeschl]

With Immich 3.0.3 and frame 1.0.36.0, it seems that even more formatting for the memory API have changed. I get formatting errors on timestamps now

ImmichFrame.Core.Api.ApiException: The HTTP status code of the response was not expected (400).
Status: 400
Response: {"message":"Validation failed","errors":[{"origin":"string","code":"invalid_format","format":"date","pattern":"/^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$/","path":["for"],"message":"Invalid input: expected ISO date string (YYYY-MM-DD), received string"}]}
at ImmichFrame.Core.Api.ImmichApi.SearchMemoriesAsync(Nullable`1 for, Nullable`1 isSaved, Nullable`1 isTrashed, Nullable`1 order, Nullable`1 size, Nullable`1 type, CancellationToken cancellationToken) in /tmp/immichframe/ImmichFrame.Core/obj/immich-openapi-specsClient.cs:line 11008
at ImmichFrame.Core.Logic.Pool.MemoryAssetsPool.LoadAssets(CancellationToken ct) in /tmp/immichframe/ImmichFrame.Core/Logic/Pool/MemoryAssetsPool.cs:line 15
at ImmichFrame.Core.Helpers.AssetExtensionMethods.ApplyAccountFilters(Task`1 unfilteredAssets, IAccountSettings accountSettings, IEnumerable`1 excludedAlbumAssets) in /tmp/immichframe/ImmichFrame.Core/Helpers/AssetExtensionMethods.cs:line 15
at Microsoft.Extensions.Caching.Memory.CacheExtensions.GetOrCreateAsync[TItem](IMemoryCache cache, Object key, Func`2 factory, MemoryCacheEntryOptions createOptions)
at ImmichFrame.Core.Logic.Pool.CachingApiAssetsPool.AllAssets(CancellationToken ct) in /tmp/immichframe/ImmichFrame.Core/Logic/Pool/CachingApiAssetsPool.cs:line 25
at ImmichFrame.Core.Logic.Pool.CachingApiAssetsPool.GetAssetCount(CancellationToken ct) in /tmp/immichframe/ImmichFrame.Core/Logic/Pool/CachingApiAssetsPool.cs:line 13
at ImmichFrame.Core.Logic.Pool.MultiAssetPool.GetAssetCount(CancellationToken ct) in /tmp/immichframe/ImmichFrame.Core/Logic/Pool/MultiAssetPool.cs:line 11
at ImmichFrame.Core.Logic.PooledImmichFrameLogic.GetTotalAssets() in 
...

[taysuus]

@taysuus I am not clear on what your issue is, or what you are suggesting. Are you on Immich v3+ and latest Frame?

Well I was thinking if that was the only issue I could try to make a PR for it, but seems not 😄