Files
OpenFUT/openfut-utas-host
funman300 3cd31c4322 fix(market): stamp the player's persona as sellerName, not EA's house name
A card listed on the Transfer Market rendered correctly in the Transfer List but
pressing it opened NO Actions panel, so Remove / Re-list were unreachable. The one
field where our auction record diverged from the oracle was the seller: we stamped
"EASFC" while the oracle stamps the account's persona name. `fut_account.py`
annotates that very property as "Blaze PDTL.DSNM / LSX GetProfileResponse Persona /
UTAS sellerName", so EA's house name on the player's OWN listing is simply wrong,
whether or not it proves to be the gate on the Actions panel.

Introduces `non_economy::PERSONA_DISPLAY_NAME` as the single source of truth and
uses it both for the `account/sync` default (previously a bare "CAGE" literal) and
as the market seller. Every listing in this store is the player's own -- there is no
NPC seller in a single-account emulator -- so the fallback is the player.

Also strengthens the differential: it compared only auctionInfo LENGTH and
tradeState, so it was structurally blind to this. It now compares the record key
set and each shared field against the live Python oracle, asserts the seller is the
persona rather than EA, and asserts itemData is the full card rather than a stub.

That strengthened comparison passes against the real oracle subprocess, which
establishes two things: our record's key set is IDENTICAL to the oracle's (we are
missing no field relative to it), and sellerName was the only divergence.

NOTE the limit of that evidence: the oracle's own Transfer List remove flow has
never been confirmed against a real client either (the only live datapoint is a
counts-tile bug), so parity is necessary but may not be sufficient. If the client
still offers no dialog, the missing field is missing on BOTH sides and must come
from client instrumentation, not from the oracle.

14 targets green, clippy clean. Deployed and verified live: sellerName='CAGE',
listing intact, coins unchanged.
2026-08-17 18:29:19 +00:00
..

openfut-utas-host

The first live FIFA 17 UTAS migration host. It fronts the client-visible UTAS port and migrates one route at a time to OpenFUT Core, proxying everything else to the Python UTAS oracle so the rest of FUT keeps working unchanged.

FIFA 17 ──HTTP──▶ openfut-utas-host
                    ├── GET …/club  ──▶ FIFA17 adapter ──▶ OpenFUT Core (/collection)
                    └── everything else ──▶ Python UTAS oracle (verbatim reverse proxy)

What it owns / does not own

Owns: socket + HTTP/1.1 keep-alive transport, route classification, the Core access client, the Python passthrough, and diagnostics. It owns no game domain state — filtering/pagination is Core's; wire parsing/shaping is the adapter's. The adapter never learns how Core is reached (the architecture rule): the host holds the [CoreAccess] boundary (GET {core_url}/collection?… today).

Safety model

  • Classification happens once, before execution. Exact GET /ut/game/<title>/club → Rust; everything else → Python. No shared path, no "try Rust then Python".
  • A Core failure on /club degrades to a valid empty {"itemData":[]} and logs an error — it never falls back to Python (which could double-apply a mutation on other routes). /club is read-only, but the rule is absolute.
  • Mutating routes (PUT/POST, /squad, /purchased, quick-sell, market, auth, SBC, /club/stats/*, /clubUser) all classify to passthrough and are untouched.

Configuration (env)

Var Required Default Meaning
OPENFUT_UTAS_HOST_ADDR yes where this host listens (client-visible UTAS addr)
OPENFUT_UTAS_PYTHON_URL yes Python UTAS oracle base URL for fallback (must differ from this host)
OPENFUT_FIFA17_CATALOG yes FIFA 17 card-definition identity catalog (Fifa17CardCatalog JSON: card id → asset id)
OPENFUT_IDENTITY_STORE yes persistent external-identity store file (owned instance → stable wire id)
OPENFUT_PERSONA_ID yes FIFA persona id stamped on GET /squad/active (must match the persona LSX/Blaze/POW/UTAS agree on)
OPENFUT_CORE_URL no http://127.0.0.1:8080 OpenFUT Core base
OPENFUT_FIFA17_TABLES_DIR no fifa17-recon/data/tables leagues/nations/teams.json for id⇄name

Startup fails clearly if the catalog or identity store cannot be loaded — there is no placeholder fallback (exactly one production identity path).

Identity model (resolved)

FIFA renders an owned card by resolving resourceId & 0xffffff against the client's own local players table; an invented id renders a blank generic card (proven live — fut_cards.py:11-21). Two distinct identities, never conflated, are resolved by [Fifa17IdentityResolver] (the single production path):

  • Definition identity (resourceId/assetId) — the card's real FIFA asset id, from the versioned OPENFUT_FIFA17_CATALOG. An unmapped definition is dropped and counted, never faked.
  • Instance identity (id) — a stable, persistent, reversible wire integer from the generic openfut-identity store under the FIFA 17 wire-id policy (monotonic from 100_000_001). The same owned instance keeps its id across restart and reverses exactly; two copies of one definition share a resourceId but get distinct ids. The namespace is globally monotonic within (fifa17, owned-item) — no per-account column is needed because Core owned-instance ids are globally-unique UUIDs.

Remaining prerequisite for a rendering retail /club: Core inventory must reference cards that exist in the catalog. The catalog + store + resolver are built and tested; wiring a controlled real FIFA 17 dev-content inventory (the curated per-game dev pack) is the next slice. rare=SP ("Special") stays UNSUPPORTED (semantics unproven; parsed, reported, never guessed).

Retail A/B runbook (first /club gate)

Change only the UTAS routing layer; keep the validated Rust Redirector/Roster and the current Blaze path. Python remains the rollback oracle — do not modify it.

Preconditions (mirror the proven blaze/roster switch discipline):

  1. cargo test -p openfut-utas-host -p openfut-adapter-fifa17 green; clippy -D warnings clean; fmt --check clean.
  2. Built binary identity == HEAD (scripts/verify-build-identity.sh); no dirty tree.
  3. Python UTAS directly reachable; the Rust host directly probeable; no stale NAT/switch rules; FIFA fully closed.

Bring-up:

  1. Move Python UTAS to an alternate port (FUT_PORT=8199 in the container/openfut-fut.sh); it keeps serving there.
  2. Start this host on the client-visible UTAS addr: OPENFUT_UTAS_HOST_ADDR=<lan>:8099 OPENFUT_UTAS_PYTHON_URL=http://127.0.0.1:8199 OPENFUT_CORE_URL=http://127.0.0.1:8080 OPENFUT_FIFA17_CATALOG=<catalog.json> OPENFUT_IDENTITY_STORE=<store.json> OPENFUT_PERSONA_ID=33068179 openfut-utas-host
  3. Launch FIFA → FUT → My Squad player picker and exercise: no-filter, position, nation, league, league+team, Gold+position, then scroll beyond page one.

Evidence to capture (all six):

  • Switch: client traffic hits the Rust host.
  • Rust positive: host log owner=RUST route=club … for the client IP.
  • Python negative for /club: Python logs no /club request in the window.
  • Python positive for other UTAS: unimplemented routes still reach Python.
  • Core positive: Core logs the /collection query and returns the expected set.
  • Application + pagination: the UI shows filtered results; later pages differ from page one (no repeated-first-page amplification).

Rollback: point the UTAS addr back at Python directly; confirm FUT still usable; then re-enable the host and confirm /club again (proves reversibility).

Logs are safe by construction: no auth/session/device/token material — only owner, route, filter summary, counts, status.