Latest iPhone app doesn't load images, hits /api/auth/validateToken constantly and takes a long time to load after #7944

Closed
opened 2026-02-05 13:25:47 +03:00 by OVERLORD · 4 comments
Owner

Originally created by @csabikaa97 on GitHub (Nov 28, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

The iPhone app is unstable for me even after complete reinstalls. When I scroll the timeline, there is a high chance that the app stops working and loading images. When this happens, I only get the followling log line with the loglevel set to Debug, nothing else:

[Nest] 35 - 11/28/2025, 6:35:55 AM DEBUG [Api:LoggingInterceptor~uih9gsts] POST /api/auth/validateToken 200 0.11ms 10.42.3.0

When I visit on the web, I can see that the assets get requested as well, but when the mobile app breaks, it only hits the /api/auth/validateToken endpoint every time I try to open a photo. In this state, even the thumbnails don't load. If I wait about a minute, and tap another photo, it sometimes starts working.

Also, when this happens, the backup icon has a red error icon in its corner, which I don't know if is relevant, but thought I should mention it.

The Websocket connection doesn't stop or restart when this issue happens.

This issue seems to be happening a lot more when scrolling the timeline quickly. My library is only about 9000 assets, but when I scroll a few months back (~1000 pictures), the app starts breaking like I described above.

I tried to wait for the image to load when the server reported only hitting the /api/auth/validateToken endpoint, and it took about 3 minutes between the successful image request and the validateToken step. Here are the logs for it:
Nest] 35 - 11/28/2025, 6:44:11 AM DEBUG [Api:LoggingInterceptor~77erzvvx] POST /api/auth/validateToken 200 0.14ms 10.42.3.0 [Nest] 35 - 11/28/2025, 6:47:49 AM DEBUG [Api:LoggingInterceptor~85mkbc3r] GET /api/assets/a76a0e11-b804-4a4a-bef1-671bb903b012/thumbnail?size=thumbnail 200 12.02ms 10.42.3.0

Considering this, the problem might be just that the validateToken request is taking a long time to process onthe iPhone app.

The OS that Immich Server is running on

Ubuntu 24.04 - Kubernetes

Version of Immich Server

v2.3.1

Version of Immich Mobile App

2.3.0 build 236

Platform with the issue

  • Server
  • Web
  • Mobile

Device make and model

iPhone 13 Pro Max

Your docker-compose.yml content

Using Kubernetes with latest helm chart (0.10.3):

controllers:
  main:
    containers:
      main:
        env:
          REDIS_HOSTNAME: '{{ printf "%s-valkey" .Release.Name }}'
          IMMICH_MACHINE_LEARNING_URL: '{{ printf "http://%s-machine-learning:3003" .Release.Name }}'
          DB_HOSTNAME: "10.43.1.9"
          DB_DATABASE_NAME: "immich"
          IMMICH_LOG_LEVEL: debug
          MACHINE_LEARNING_MODEL_TTL: 0
          MACHINE_LEARNING_PRELOAD__CLIP__TEXTUAL: immich-app/XLM-Roberta-Large-Vit-B-16Plus
          DB_USERNAME:
            valueFrom:
              secretKeyRef:
                name: immich-db-felhasznalonev-secret
                key: db-felhasznalonev
          DB_PASSWORD:
            valueFrom:
              secretKeyRef:
                name: immich-db-jelszo-secret
                key: db-jelszo

immich:
  metrics:
    enabled: false
  persistence:
    library:
      existingClaim: immich-image-storage-pvc
  configuration: {}

valkey:
  enabled: true
  persistence:
    data:
      enabled: true
      size: 8Gi
      type: persistentVolumeClaim
      accessMode: ReadWriteOnce
      storageClass: rook-cephfs

Your .env content

From Kubernetes

- env:
    - name: DB_DATABASE_NAME
      value: immich
    - name: DB_HOSTNAME
      value: 10.43.1.9
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          key: db-jelszo
          name: immich-db-jelszo-secret
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          key: db-felhasznalonev
          name: immich-db-felhasznalonev-secret
    - name: IMMICH_LOG_LEVEL
      value: debug
    - name: IMMICH_MACHINE_LEARNING_URL
      value: http://immich-machine-learning:3003
    - name: MACHINE_LEARNING_MODEL_TTL
      value: "0"
    - name: MACHINE_LEARNING_PRELOAD__CLIP__TEXTUAL
      value: immich-app/XLM-Roberta-Large-Vit-B-16Plus
    - name: REDIS_HOSTNAME
      value: immich-valkey

Reproduction steps

  1. Open iPhone immich app
  2. Start scrolling the timeline until the thumbnails or the images don't load
  3. Look at server logs
    ...

Relevant log output


Additional information

No response

Originally created by @csabikaa97 on GitHub (Nov 28, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug The iPhone app is unstable for me even after complete reinstalls. When I scroll the timeline, there is a high chance that the app stops working and loading images. When this happens, I only get the followling log line with the loglevel set to Debug, nothing else: `[Nest] 35 - 11/28/2025, 6:35:55 AM DEBUG [Api:LoggingInterceptor~uih9gsts] POST /api/auth/validateToken 200 0.11ms 10.42.3.0` When I visit on the web, I can see that the assets get requested as well, but when the mobile app breaks, it only hits the /api/auth/validateToken endpoint every time I try to open a photo. In this state, even the thumbnails don't load. If I wait about a minute, and tap another photo, it sometimes starts working. Also, when this happens, the backup icon has a red error icon in its corner, which I don't know if is relevant, but thought I should mention it. The Websocket connection doesn't stop or restart when this issue happens. This issue seems to be happening a lot more when scrolling the timeline quickly. My library is only about 9000 assets, but when I scroll a few months back (~1000 pictures), the app starts breaking like I described above. I tried to wait for the image to load when the server reported only hitting the /api/auth/validateToken endpoint, and it took about 3 minutes between the successful image request and the validateToken step. Here are the logs for it: `Nest] 35 - 11/28/2025, 6:44:11 AM DEBUG [Api:LoggingInterceptor~77erzvvx] POST /api/auth/validateToken 200 0.14ms 10.42.3.0 [Nest] 35 - 11/28/2025, 6:47:49 AM DEBUG [Api:LoggingInterceptor~85mkbc3r] GET /api/assets/a76a0e11-b804-4a4a-bef1-671bb903b012/thumbnail?size=thumbnail 200 12.02ms 10.42.3.0` Considering this, the problem might be just that the validateToken request is taking a long time to process onthe iPhone app. ### The OS that Immich Server is running on Ubuntu 24.04 - Kubernetes ### Version of Immich Server v2.3.1 ### Version of Immich Mobile App 2.3.0 build 236 ### Platform with the issue - [ ] Server - [ ] Web - [x] Mobile ### Device make and model iPhone 13 Pro Max ### Your docker-compose.yml content ```YAML Using Kubernetes with latest helm chart (0.10.3): controllers: main: containers: main: env: REDIS_HOSTNAME: '{{ printf "%s-valkey" .Release.Name }}' IMMICH_MACHINE_LEARNING_URL: '{{ printf "http://%s-machine-learning:3003" .Release.Name }}' DB_HOSTNAME: "10.43.1.9" DB_DATABASE_NAME: "immich" IMMICH_LOG_LEVEL: debug MACHINE_LEARNING_MODEL_TTL: 0 MACHINE_LEARNING_PRELOAD__CLIP__TEXTUAL: immich-app/XLM-Roberta-Large-Vit-B-16Plus DB_USERNAME: valueFrom: secretKeyRef: name: immich-db-felhasznalonev-secret key: db-felhasznalonev DB_PASSWORD: valueFrom: secretKeyRef: name: immich-db-jelszo-secret key: db-jelszo immich: metrics: enabled: false persistence: library: existingClaim: immich-image-storage-pvc configuration: {} valkey: enabled: true persistence: data: enabled: true size: 8Gi type: persistentVolumeClaim accessMode: ReadWriteOnce storageClass: rook-cephfs ``` ### Your .env content ```Shell From Kubernetes - env: - name: DB_DATABASE_NAME value: immich - name: DB_HOSTNAME value: 10.43.1.9 - name: DB_PASSWORD valueFrom: secretKeyRef: key: db-jelszo name: immich-db-jelszo-secret - name: DB_USERNAME valueFrom: secretKeyRef: key: db-felhasznalonev name: immich-db-felhasznalonev-secret - name: IMMICH_LOG_LEVEL value: debug - name: IMMICH_MACHINE_LEARNING_URL value: http://immich-machine-learning:3003 - name: MACHINE_LEARNING_MODEL_TTL value: "0" - name: MACHINE_LEARNING_PRELOAD__CLIP__TEXTUAL value: immich-app/XLM-Roberta-Large-Vit-B-16Plus - name: REDIS_HOSTNAME value: immich-valkey ``` ### Reproduction steps 1. Open iPhone immich app 2. Start scrolling the timeline until the thumbnails or the images don't load 3. Look at server logs ... ### Relevant log output ```shell ``` ### Additional information _No response_
Author
Owner

@bo0tzz commented on GitHub (Nov 28, 2025):

When I visit on the web, I can see that the assets get requested as well, but when the mobile app breaks, it only hits the /api/auth/validateToken endpoint every time I try to open a photo. In this state, even the thumbnails don't load. If I wait about a minute, and tap another photo, it sometimes starts working.

Do you mean that the web client also breaks?

@bo0tzz commented on GitHub (Nov 28, 2025): > When I visit on the web, I can see that the assets get requested as well, but when the mobile app breaks, it only hits the /api/auth/validateToken endpoint every time I try to open a photo. In this state, even the thumbnails don't load. If I wait about a minute, and tap another photo, it sometimes starts working. Do you mean that the web client _also_ breaks?
Author
Owner

@csabikaa97 commented on GitHub (Nov 28, 2025):

This only occurs for me when using the iPhone app. The web version works fine as far as I can tell.

@csabikaa97 commented on GitHub (Nov 28, 2025): This only occurs for me when using the iPhone app. The web version works fine as far as I can tell.
Author
Owner

@alextran1502 commented on GitHub (Nov 28, 2025):

Does it happen on direct IP access? Could it be a DNS settings problem?

@alextran1502 commented on GitHub (Nov 28, 2025): Does it happen on direct IP access? Could it be a DNS settings problem?
Author
Owner

@csabikaa97 commented on GitHub (Nov 29, 2025):

It doesn't happen with direct IP access. I will test some things with my infrastructure tomorrow to see what could've caused the problem, but I'm starting to doubt it is Immich actually.

@csabikaa97 commented on GitHub (Nov 29, 2025): It doesn't happen with direct IP access. I will test some things with my infrastructure tomorrow to see what could've caused the problem, but I'm starting to doubt it is Immich actually.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#7944