Files
OpenFUT/openfut-utas-host
funman300 fb38ee6087 fifa17: claim five routes whose handlers were already unreachable
Read the client's COMPLETE UTAS route surface out of CardsDLL's .rdata in the
running process (new tools/url_template_probe.py) and probed every one against
staging, where the Python upstream is deliberately dead so anything the Rust host
does not own answers 502 instead of being silently proxied.

That found five routes whose handlers already existed and were dead code because
`classify` never produced their Route -- the same defect as `season/list` and
`watchList`, whose fix comments are still in the file. This is the third and
fourth time:

  captcha        -> handle_static_ack, which already returns the oracle's exact
                    {encodedImg,sequence,sizeBeforeEncode}
  tfa            -> handle_static_ack, {}
  livemessage    -> handle_static_ack, {}
  activeMessage  -> handle_static_ack, {}
  tournament/user-> FeatureOffEmpty, {} == the oracle with FUT_MODES off
                    (tools/utas_server.py:1504); the client builds this literal
                    at CardsDLL 0x18021e540 and the bare `tournament` arm never
                    matched it

Route's own doc comment already claimed the first four as "Rust-owned
UNCONDITIONAL", so the documentation was wrong rather than the intent. All five
are byte-identical to the oracle, so claiming them is parity, not new behaviour.
Invisible in production because the upstream answers there.

Two tests pin the vocabularies so a handler cannot go unreachable a fifth time;
both are mutation-checked (removing the captcha arm fails the first).

Also documents the surface in docs/CLIENT_ROUTE_SURFACE.md, including the trap
that bit me repeatedly: an .rdata literal is a FRAGMENT, not a callable path.
`clientdata`, `purchasegroup`, `sbs/challenges`, `squadBuildingSets`, `club/items`
and `item` all looked unserved and are not. Only `squad/mode` is genuinely
unserved, and correctly so -- it is Draft-only, which is out of scope.

L5 finding: there is NO consumable-apply route anywhere in the binary. The only
owned-item mutations the client can express are PUT item (move/pile), DELETE
item/<id> and POST delete/item (quick sell), and PUT squad. So applying a
consumable is not a dedicated endpoint; L5/L6 must be pursued by capturing the
PUT item payload, not by implementing a route that does not exist.

Host 123 lib + 45 host_test, fmt and clippy clean. tournament/user, livemessage
and activeMessage verified 200 on staging (were 502).
2026-08-21 23:28:29 +00:00
..

openfut-utas-host

The FIFA 17 UTAS migration boundary. It accepts the client-visible HTTP surface, serves migrated routes from Rust/Core plus host-owned durable stores, and proxies only the unclassified tail to the Python behavioral oracle.

FIFA 17 ──HTTP──▶ openfut-utas-host
                    ├── migrated route ──▶ Rust adapter / Core / host stores
                    └── unclassified tail ──▶ Python UTAS oracle

src/lib.rs::classify is the route-level source of truth. The current Rust surface includes club/squad/user reads, club rename, auth/session/client data, Store/economy, packs, owned-item moves, market/trade-pile, and the observed hub support routes.

Safety model

  • Classification happens exactly once before execution. There is no "try Rust then Python"; a mutation cannot be double-applied.
  • A route classified to Rust never falls back to Python on a Core/store/projection failure. Each handler uses its captured fail-closed or honest-empty wire contract.
  • PUT …/club and PUT|POST …/user/club atomically update the shared account JSON. Every input returns the required zero-atom 200 {} response; rejection and persistence failures remain visible in logs.
  • Numeric GET …/squad/<n> returns the one Core-backed current squad, matching the Python oracle's single-current-squad behavior.
  • Python remains the behavioral oracle and rollback backend for routes not yet classified to Rust. New economy behavior belongs in Rust/Core, never Python.

Configuration (env)

Var Required Default Meaning
OPENFUT_UTAS_HOST_ADDR yes client-visible host listen address
OPENFUT_UTAS_PYTHON_URL yes Python oracle base for the unclassified tail; must differ from this host
OPENFUT_FIFA17_CATALOG yes FIFA 17 definition identity catalog
OPENFUT_IDENTITY_STORE yes persistent owned-instance ↔ wire-id store
OPENFUT_PERSONA_ID yes non-zero FIFA persona id shared by LSX/Blaze/POW/UTAS
OPENFUT_MARKET_DB yes durable host-owned transfer-market SQLite DB
OPENFUT_PILE_DB yes durable host-owned item-pile SQLite DB
OPENFUT_CORE_URL no http://127.0.0.1:8080 OpenFUT Core base
OPENFUT_FIFA17_TABLES_DIR no fifa17-recon/data/tables FIFA entity tables
OPENFUT_CLIENTDATA_DB no identity-store sibling clientdata.json durable opaque client-data JSON
OPENFUT_ACCOUNT_PATH no FUT_ACCOUNT_PATH, then identity-store sibling active_account.json shared FIFA account/club JSON

Startup fails if required identity or durable economy state cannot be opened. No placeholder production identity source is substituted.

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.

Production has a frozen post-P1 baseline and a hot Python rollback. A source change passing local tests is not deployment approval. Build verification, staging, host restart, and live-client promotion remain operator-gated; the current state and promotion evidence live in the OpenFUT Obsidian vault.

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