Skip to content

feat(presence): publish the network-wide player lookup#22

Merged
hbrombeer merged 3 commits into
mainfrom
feat/session-query
Jul 12, 2026
Merged

feat(presence): publish the network-wide player lookup#22
hbrombeer merged 3 commits into
mainfrom
feat/session-query

Conversation

@hbrombeer

Copy link
Copy Markdown
Member

Why

plugin-proxy's ProxyServiceImpl already resolves a player locally first and falls back to a PlayerSessionQuery for anyone on another proxy. Nothing ever registered one, so that fallback returned null — a proxy could only ever see its own players. That is the reason /msg and party invites silently did not cross proxies.

What

PlayerSessionQueryImpl registers into the ProxyServiceRegistry and answers from service-player (contract library-grpc-contracts-player:0.3.0):

  • resolveByName(name) → the session, network-wide
  • getSession(playerId) → who and where
  • suggestNames(prefix, limit) → tab-complete, prefix-based and capped (never a roster dump)

Every lookup fails soft: an unavailable presence service means "I don't know", and the caller falls back to what it can see locally. These run on the command path — an exception there would land on Velocity's event loop.

TryPlayerLogin now carries the player's name and PROXY_ID. Without the name a session exists but nobody can address it by name, which is the whole point. ServerConnectedEvent keeps the session pointing at the backend the player is actually on, so a party warp can send someone to the leader's server.

plugin-proxy is now a hard plugin dependency (@Plugin(dependencies = ...)) and plugin-proxy-api is compileOnly — it must not be shaded, or the registry this plugin writes into would be a different class from the one chat and social read.

Chain

groundsgg/library-grpc-contracts#68 (player 0.3.0) → groundsgg/service-player#75 (implements the RPCs) → this → plugin-chat + plugin-social drop their local-only lookups and use ProxyService.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E92vTegZqXd2HqjE7jnDJz

hbrombeer and others added 3 commits July 12, 2026 21:02
plugin-proxy's ProxyService resolves a player locally and then falls back to
a PlayerSessionQuery — but nothing ever registered one, so the fallback
returned null and a proxy could only ever see its own players. That is why
/msg and party invites did not cross proxies.

Register one, backed by service-player (contract 0.3.0): name -> uuid,
uuid -> session, and prefix suggestions for tab-complete. Every lookup fails
soft — an unavailable presence service means "unknown", and the caller falls
back to the players it can see locally, rather than an exception on Velocity's
event loop.

Login now carries the player's name and PROXY_ID: without the name a session
exists but nobody can address it, and ServerConnectedEvent keeps the session
pointing at the backend the player is actually on.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E92vTegZqXd2HqjE7jnDJz
plugin-player has never shipped an image, so the platform bundle could not
deploy it — and without it in the proxy, nothing registers the session lookup
that cross-proxy chat and social depend on.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E92vTegZqXd2HqjE7jnDJz
service-player runs with `grounds.auth.enabled=true` and rejects calls
without a Bearer token with UNAUTHENTICATED — and every failure in this
client is swallowed into "unknown". Logins would have looked like a flaky
presence service, and the whole cross-proxy lookup chain would have failed
silently.

Attach the projected ServiceAccount JWT (audience grounds-services) the
charts already mount into the proxy pod, re-read per call for kubelet
rotation.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E92vTegZqXd2HqjE7jnDJz
@hbrombeer hbrombeer merged commit 0fe9603 into main Jul 12, 2026
3 of 6 checks passed
@hbrombeer hbrombeer deleted the feat/session-query branch July 12, 2026 20:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant