mirror of
https://github.com/jcreek/CosmicClash.git
synced 2026-09-10 16:04:04 +00:00
Josh Creek
fd18cf6ac0
Investigated the Fleet-manifest wiring task flagged last commit and found a deeper, previously-undesigned gap: Kubernetes env vars are fixed at pod creation, but Agones allocates a match to an already- running Ready pod well after it starts -- so there was no channel at all for match-specific data (match ID) to reach that pod's processes. Close it using the Agones GameServerAllocation API's documented spec.metadata.annotations field, which Agones applies to the allocated GameServer's own object_meta on success: server/agones.Client.Allocate now requests cosmic-clash.io/match-id and cosmic-clash.io/allocation-id annotations, and the supervisor reads them back from the same /gameserver SDK call it already makes for the assigned port/address (GameServer.ObjectMeta.Annotations), falling back to them for its own control-plane registration only when MatchID isn't explicitly configured -- an explicit value always wins, and a match ID resolvable from neither source fails Start() closed before any HTTP call. The exact object_meta vs objectMeta JSON key from a live Agones SDK sidecar is not independently verified from this sandbox; documented inline, and the fallback degrades safely (empty annotations map, same as before this change) if it turns out to be wrong. Covered by two new tests: the annotation actually flowing through to the registration body, and fail-closed with neither config nor annotation supplying a match ID (registerCalled stays false, not just that Start() errors).