bridge: LoginRequest platform must match the game's own OVR_ORG identity (join failed with 'requesting player not found in match')

Closed
  • Is something wrong?
#54 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
15/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
backend

Research direction

The issue says the fix is already present in commit d8be43b, so first inspect that change and the related code in src/runtime/compat/ws_bridge.cpp. The reported live verification reached in-game, meaning the described join failure is resolved. The remaining questions are separate and open-ended; this issue is not a good first contribution as written.

Written by the indexing model from the issue text.

Description

bug

A token-auth client (no config.yaml identity, /nevr ingress, cached credentials) logged in and reached the social_2.0 lobby host but never joined: the game sat on the MATCHMAKING screen for 60 seconds and ended at Server connection failed (client nevr-2026-09-30T18-17-03.097.jsonl, main @ 05561b7).

Cause, from the server's own log: 2026-09-30T18:17:25.231Z error server/evr_pipeline.go:739 "Pipeline error": "requesting player not found in match: OVR-ORG-<id>" for *evr.LobbyPlayerSessionsRequest.

  • The bridge logged the client in with SelectPlatformCode = platform 6 (DMO, because of -noovr) on the token path; the runtime labels this DSC-NOVR.
  • In the same path the bridge forces the game's own user to provider 4 (OVR_ORG): *loginState = (*loginState & ~0xF) | 4 in src/runtime/compat/ws_bridge.cpp. The game then names itself OVR-ORG-<id> in every later request.
  • Nakama had registered the entrant under the login's platform (DMO), so the LobbyPlayerSessionsRequest for OVR-ORG-<id> found no such player; the host never accepted it.

Every run that reached in game earlier had logged in with URL credentials, which already selected platform 4.

Fix (d8be43b): SelectPlatformCode always returns kBridgeLoginPlatform (4, OVR_ORG), the same constant the login-state patch uses, so the two cannot drift. Verified live 2026-09-30 (no config files, cached token auth): login injected xpid=OVR-ORG-… platform=4, LOGIN SUCCESS, received player sessions success for 1 players, received join accepted for 1 entrants, NetClientLobby … to joined, NetGame … to in game.

Still open: why the earlier 400 at login looked like a platform problem (it was the /ws path dropping the JWT, #52); whether platform 6 (-noovr) should ever be used (nothing in the game uses it after login); the ordered-precedence tests were replaced by one test that pins every input to 4.

Dominant language
C++
Stars
2
Forks
5
Avg merge
5h 9m
Merged PRs (30d)
949

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EchoTools/nevr-runtime

All issues in EchoTools/nevr-runtime

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.