fifa17-recon: S18d -- a testable hypothesis for the Seasons blocker

/leaderboards/options is the ONLY mode-related endpoint the real client has ever requested, and we answer {} because FUT_MODES is off. Three of its seven occurrences are followed within ~2 minutes by /user/accountinfo and a fresh /ut/auth, which is the signature of hitting an error, returning to the main menu, and re-entering FUT. Hypothesis: the client fetches mode options on entering the play area, caches them, and later refuses Seasons from that cached EMPTY body without issuing another request. That would explain the zero-requests-at-failure observation, which no response-shape theory has been able to account for: the deciding fetch happened minutes earlier. Stated as a hypothesis, not a finding. The correlation is real; the causation is not established. Cheap to test: leaderboard_route already implements an options body behind FUT_MODES=1. Risk noted in advance: FUT_MODES=1 also enables /season, whose array-root shape is a flagged freeze candidate. That risk cannot fire while the client never asks. If this hypothesis is right, a populated options body is precisely what would make it ask for the first time, so succeeding at step one arms step two. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
2026-08-04 11:33:56 -07:00
parent b7943aead3
commit 38b10e5ec5
1 changed files with 41 additions and 0 deletions
@@ -781,3 +781,44 @@ missing; nobody looked.
 All four are now routed. The value here is the method: the unmapped view is a standing
 detector for the suffix endpoints the binary's URL template table cannot show, which
 have now caught this project four separate times. Run it after every session.
+
+### 18d. A hypothesis for Seasons: the deciding fetch happens minutes earlier
+
+`/leaderboards/options` is the ONLY mode-related endpoint the real client has ever
+requested. It has been requested seven times, and we answer `{}` because `FUT_MODES` is
+off. What follows each request:
+
+```
+20:41:02  ->  135s   -> /user/accountinfo, then a fresh /ut/auth
+22:27:40  ->  gap    -> /user/accountinfo, then a fresh /ut/auth
+09:51:07  ->    1s   -> /club/stats/staff        (normal play continued)
+09:55:21  ->  126s   -> /user/accountinfo, then a fresh /ut/auth
+09:57:47  -> 2127s   -> /hub
+11:12:32  ->   12s   -> /clientdata/userHubData  (normal play continued)
+11:16:33  ->  274s   -> /hub
+```
+
+A following `/ut/auth` means the FUT session ended and the client logged in again, which
+is the exact signature of hitting an error, being returned to the main menu, and going
+back into FUT. Three of the seven have it.
+
+**The hypothesis.** The client fetches mode/leaderboard options when it enters the play
+area, caches the result, and later refuses Seasons based on that cached EMPTY body,
+issuing no further request. That would explain the otherwise strange observation that
+the failure produces zero requests at any layer: the deciding data was fetched two
+minutes earlier and we returned nothing in it.
+
+This is a hypothesis, not a finding. What is factual: the correlation above, and that
+the one mode endpoint the client asks for is the one we stub.
+
+**Why it is worth testing first.** It is cheap. `leaderboard_route()` already implements
+an options body (`{"category":0,"id":0,"period":0,"view":0,"url":""}`) behind
+`FUT_MODES=1`, so the test is one flag and one menu selection.
+
+**The conditional risk, stated in advance.** `FUT_MODES=1` also enables `/season`, whose
+array-root shape was flagged as a freeze candidate. That risk cannot fire while the
+client never asks for `/season`. But if this hypothesis is RIGHT, then a populated
+options body is exactly what would make the client proceed and ask for `/season` for the
+first time. So success on the first step arms the second risk. Expect it, watch for the
+busy-loop freeze rather than an error dialog, and be ready to answer `/season`
+minimally rather than fully.