Native app clients get HTTP 404 on POST /api/v4/call/{token} — ParticipantService actorCache returns session-less participant for app-password auth

[Frisch12]

How to use GitHub

• Please use the 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Authenticate a native Talk client (iOS v23.0.1) via app-password/token authentication (no PHP session cookie).
2. Join or receive a call in any conversation room.
3. The client calls POST /api/v4/call/{token} to join the call.

Expected behaviour

The call should be joined successfully (HTTP 200), just as it works in the browser for the same user, room, and Talk version.

Actual behaviour

The API returns HTTP 404. The iOS app displays:

"Anruf kann nicht angenommen werden / Unterhaltung nicht gefunden oder nicht beigetreten"
("Call cannot be accepted / Conversation not found or not joined")

This occurs 100% of the time on native clients. Browser-based calls work fine.

Root cause: Manager::getRoomForUserByToken() caches a Participant without a session in ParticipantService::$actorCache when $sessionId is null. For native app clients, TalkSession::getSessionForRoom() returns null because there is no PHP session cookie — the OCP\ISession is a stateless in-memory session that doesn't persist between requests.

Detailed trace

1. InjectionMiddleware::getLoggedInOrGuest() calls Manager::getRoomForUserByToken($token, $userId, null).

2. In [getRoomForUserByToken()](https://github.com/nextcloud/spreed/blob/v23.0.1/lib/Manager.php#L700), the session LEFT JOIN is skipped because $sessionId is null:

if ($sessionId !== null) {  // null for app-password auth → SKIPPED
    $helper->selectSessionsTable($query);
    $query->leftJoin('a', 'talk_sessions', 's', ...);
}

3. The participant is created without session data and cached:

$participant = $this->createParticipantObject($room, $row);
$this->participantService->cacheParticipant($room, $participant);  // cached WITHOUT session

4. Back in getLoggedInOrGuest(), getParticipant($room, $userId) is called with default $sessionId = null.

5. In [ParticipantService::getParticipant()](https://github.com/nextcloud/spreed/blob/v23.0.1/lib/Service/ParticipantService.php#L2233), the !$sessionId shortcut returns the cached null-session participant — the DB LEFT JOIN to talk_sessions never executes:

if (isset($this->actorCache[...][...][...])) {
    $participant = $this->actorCache[...];
    if (!$sessionId  // !null → true → RETURNS CACHED WITHOUT SESSION
        || ($participant->getSession() instanceof Session
            && $participant->getSession()->getSessionId() === $sessionId)) {
        return $participant;
    }
}

6. CallController::joinCall() checks $this->participant->getSession() → null → returns HTTP 404.

Proof

Adding debug instrumentation to joinCall() to query talk_sessions directly at the moment of the 404 shows 10 active sessions (state=1) for the user in the database. The sessions exist — they are just never loaded.

Proposed fix

In ParticipantService::getParticipant(), change the actorCache hit condition so that a null-session cached participant is not returned when the caller requests a session ($sessionId = null):

// Before:
if (!$sessionId
    || ($participant->getSession() instanceof Session
        && $participant->getSession()->getSessionId() === $sessionId)) {
    return $participant;
}

// After:
if ($sessionId === false
    || ($participant->getSession() instanceof Session
        && (!$sessionId || $participant->getSession()->getSessionId() === $sessionId))) {
    return $participant;
}

This ensures:

• $sessionId === false (caller doesn't need session) → return cached, preserving performance.
• $sessionId === null (caller wants any session) → only return cached if it actually has a session; otherwise fall through to DB query.
• $sessionId === "specific" → only return cached if it matches.

Related issues:

• API for joining a call does only work with cookies #8559 — "API for joining a call does only work with cookies"
• Re-join room when starting a call results in 404 talk-ios#1756 — "Re-join room when starting a call results in 404"
• Try to forceReconnect on 404 when joining call talk-ios#1777 — "Try to forceReconnect on 404 when joining call" (client-side workaround)

Note: The // FIXME PROBLEM comment at the null-$sessionId LEFT JOIN branch in getParticipant() suggests this area was already known to be problematic.

Talk app

Talk app version: v23.0.1

**Custom Signaling server configured: ** strukturag/nextcloud-spreed-signaling:latest

Browser

Not applicable — this bug affects native app clients only. Browser-based calls work correctly.

Microphone available: n/a

Camera available: n/a

Operating system: iOS (Talk iOS app v23.0.1)

Browser name: n/a

Browser version: n/a

Browser log

Details

n/a — native app issue, not browser-related.

Server configuration

Operating system: Docker FPM Alpine 33.0.0

Web server: Nginx (behind nginx ingress, 2 Nextcloud replicas)

Database: MariaDB Galera (3-node cluster)

Nextcloud Version: 33.0.0

List of activated apps:

Details

Enabled:
  - activity: 6.0.0-dev.0
  - admin_audit: 1.23.0
  - app_api: 33.0.0
  - approval: 3.1.0
  - bruteforcesettings: 6.0.0-dev.0
  - calendar: 6.2.1
  - circles: 33.0.0
  - cloud_federation_api: 1.17.0
  - collectives: 4.0.0
  - comments: 1.23.0
  - contacts: 8.4.1
  - contactsinteraction: 1.14.1
  - dashboard: 7.13.0
  - dav: 1.36.0
  - deck: 1.17.0
  - federatedfilesharing: 1.23.0
  - federation: 1.23.0
  - files: 2.5.0
  - files_downloadlimit: 5.1.0-dev.0
  - files_pdfviewer: 6.0.0-dev.0
  - files_reminders: 1.6.0
  - files_sharing: 1.25.2
  - files_trashbin: 1.23.0
  - files_versions: 1.26.0
  - firstrunwizard: 6.0.0-dev.0
  - forms: 5.2.5
  - groupfolders: 21.0.6
  - logreader: 6.0.0
  - lookup_server_connector: 1.21.0
  - mail: 5.7.2
  - nextcloud_announcements: 5.0.0
  - notes: 4.13.0
  - notifications: 6.0.0
  - notify_push: 1.3.0
  - oauth2: 1.21.0
  - password_policy: 5.0.0-dev.0
  - photos: 6.0.0-dev.0
  - privacy: 5.0.0-dev.0
  - profile: 1.2.0
  - provisioning_api: 1.23.0
  - recommendations: 6.0.0-dev.0
  - related_resources: 4.0.0-dev.0
  - richdocuments: 10.1.0
  - serverinfo: 5.0.0-dev.0
  - settings: 1.16.0
  - sharebymail: 1.23.0
  - spreed: 23.0.1
  - support: 5.0.0
  - survey_client: 5.0.0-dev.0
  - suspicious_login: 11.0.0-dev.0
  - systemtags: 1.23.0
  - tasks: 0.17.1
  - text: 7.0.0-dev.3
  - theming: 2.8.0
  - twofactor_backupcodes: 1.22.0
  - twofactor_totp: 15.0.0-dev.0
  - updatenotification: 1.23.0
  - user_ldap: 1.24.0
  - user_status: 1.13.0
  - viewer: 6.0.0-dev.0
  - weather_status: 1.13.0
  - webhook_listeners: 1.5.0
  - whiteboard: 1.5.7
  - workflowengine: 2.15.0
Disabled:
  - encryption: 2.21.0
  - files_external: 1.25.1
  - twofactor_nextcloud_notification: 7.0.0

Nextcloud configuration:

Details

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "nextcloud.nextcloud-test.example.org",
            "nextcloud-chart.nextcloud.svc.cluster.local"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "33.0.0.16",
        "overwrite.cli.url": "https:\/\/nextcloud.nextcloud-test.example.org",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 26379,
            "masterName": "nextcloud-redis",
            "sentinels": [
                {
                    "host": "nextcloud-chart-redis.nextcloud.svc.cluster.local",
                    "port": 26379
                }
            ],
            "timeout": 1.5,
            "read_timeout": 1.5
        },
        "overwriteprotocol": "https",
        "upgrade.disable-web": true,
        "app_install_overwrite": [
            "spreed",
            "mail",
            "calendar",
            "contacts",
            "tasks",
            "deck",
            "notes",
            "forms",
            "collectives",
            "whiteboard",
            "richdocuments",
            "groupfolders",
            "user_ldap",
            "twofactor_totp",
            "admin_audit",
            "suspicious_login",
            "terms_of_service",
            "approval",
            "notify_push"
        ],
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "appstoreenabled": false,
        "updatechecker": false,
        "loglevel": 2,
        "maintenance": false,
        "log_type": "file",
        "logfile": "\/var\/www\/html\/data\/nextcloud.log",
        "default_phone_region": "DE",
        "skeletondirectory": "",
        "default_locale": "de_DE",
        "maintenance_window_start": "1"
    }
}

[SystemKeeper]

Do I understand correctly, if you use an app password to login it does not work, but if you login with username and password it works?

[Frisch12]

Not quite — the distinction isn't really about which password you use, but about how the client handles sessions.
The browser works because it sends a PHP session cookie with every request. That cookie is what makes TalkSession::getSessionForRoom() return a valid session ID, which triggers the database JOIN that loads session data into the participant object.
Native apps (iOS, Android) authenticate via app-password tokens in HTTP headers, but they don't carry a PHP session cookie — there's no cookie jar in the same sense. So OCP\ISession is just a stateless in-memory object that doesn't persist between requests. That means $sessionId comes back as null, the session JOIN gets skipped, and the participant is cached without session data. When joinCall() then checks for a session, it finds null and returns 404.
So the real trigger is: no PHP session cookie → no session loaded → 404. App-password auth is just the standard way native clients authenticate, and it happens to never produce that cookie. If you could hypothetically make a native client send a valid PHP session cookie alongside the app-password token, it would probably work too — but that's not how the native auth flow works.

[SystemKeeper]

Native apps (iOS, Android) authenticate via app-password tokens in HTTP headers, but they don't carry a PHP session cookie — there's no cookie jar in the same sense.

We do, that’s why I ask. And that works perfectly fine, that’s why I am wondering what is different for you. Otherwise nobody would be able to use the mobile apps to do calls

[Frisch12]

You're right, that's a fair point — I need to dig deeper into what exactly triggers this in my environment.

The proposed fix did resolve the issue for me, but I'd been chasing a configuration issue for three days before landing on the code path, so I can't rule out that something in my setup is the actual root cause.

If you're interested and have the time, I'd be happy to have a private conversation about my system setup to narrow it down further.

[Frisch12]

Closing this — the root cause turned out to be on my side.

TL;DR: Missing Redis session locking in a multi-instance Nextcloud setup.

The native apps (iOS/Android) handle connections differently from the browser and have a rapid retry mechanism. With multiple Nextcloud replicas, this leads to concurrent requests reading and writing the same PHP session simultaneously. Without proper session locking, one request reads the session before another has finished writing the Talk session key into it — resulting in $sessionId being null and triggering the 404.

The browser never hits this because it doesn't fire parallel requests the same way.

The fix was configuring Redis session locking (redis.session.locking_enabled, redis.session.lock_retries, redis.session.lock_wait_time) so that concurrent session access is serialized properly.

Apologies for the noise, and thanks to @SystemKeeper for pushing back — that pointed me in the right direction.