refactor(server): extract shop + inject get_progression_content into the seam (R3) - #851
Conversation
📝 WalkthroughWalkthroughThe cosmetics shop endpoints moved from ChangesCosmetics shop router extraction
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
…ntent into the seam (R3) The progression-content substrate: `_get_progression_content` (a lazy, double-checked-locking content cache) is now published into the appstate seam as a CALLABLE. The cache global + lock + the function stay in server.py (startup uses it, and test_progression_api patches `server._progression_content` directly), so ZERO test retargeting — routers just call `appstate.get_progression_content()`. Because the accessor is defined at server.py:1152 but the import-top configure() runs at :346, a second `appstate.configure(get_progression_content=...)` publishes it right after the def (configure is idempotent/additive). First consumer: routers/shop.py (3 routes: buy/equip/list). Bodies verbatim; @app -> @router, meta_db -> appstate.meta_db, _clean_str from reqfields, _get_progression_content() -> appstate.get_progression_content(). This unblocks stats/progression/profile next (all share the accessor). server.py: 7,880 -> 7,845. Verified: pyflakes clean; route table IDENTICAL (143); pytest 2401 passed (test_progression_api's server._progression_content patch still works via the kept cache); packaging guard; eslint 0. Boot smoke: GET /api/shop 200 (drives appstate.get_progression_content), buy 400 on bad body. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
69367ab to
37ac50a
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/size-exemptions.md`:
- Around line 58-59: Update the size metrics in the affected entry of
docs/size-exemptions.md to match the PR objective’s reported reduction from
7,880 to 7,845 lines, replacing the conflicting 7,798 and 14,037 values while
preserving the surrounding ratcheting context.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 57f3e87a-65ff-450f-a0c7-493dd40adeec
📒 Files selected for processing (4)
docs/size-exemptions.mdlib/appstate.pylib/routers/shop.pyserver.py
|
The register value 7,798 is correct for the current branch state. This PR was rebased onto #850 (library_extras, which took server.py 7,880 → 7,833); shop's cut then brought it to 7,798 (verified: |
…sion.py (R3) (#853) 4 routes (overview/add-paths/onboarding/events, spec 010) + their EXCLUSIVE helpers (_goal_ui_progress, _progression_overview 112L) + the _PROGRESSION_EVENT_TYPES whitelist. Bodies verbatim; @app -> @router, meta_db -> appstate.meta_db, _clean_str from reqfields. The two SHARED server accessors read through the seam: get_progression_content (added for shop #851) and builtin_diagnostic_filename (new slot — a trivial const-returning fn shared with the stats router's api_record_stats). Both are injected via the second appstate.configure() after their defs (the import-top configure runs before them). The cache + fns stay in server.py, so test_progression_api's server._progression_content patch is untouched — 0 retarget. server.py: 7,798 -> 7,594. Verified: pyflakes clean; route table IDENTICAL (143); both seam accessors wired; pytest 2401 passed (63 in test_progression_api); eslint 0. Boot smoke: GET /api/progression 200 (drives _progression_overview + both accessors), events 400 on bad body. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The progression-content substrate, proven by its first consumer (
shop)._get_progression_content— a lazy, double-checked-locking content cache — is now published into theappstateseam as a callable. The cache global, its lock, and the function all stay inserver.py(startup uses it, andtest_progression_apipatchesserver._progression_contentdirectly), so zero test retargeting — routers just callappstate.get_progression_content().Since the accessor is defined at
server.py:1152but the import-topconfigure()runs at:346, a secondappstate.configure(get_progression_content=…)publishes it right after the def (configureis idempotent/additive).First consumer:
routers/shop.py(3 routes). Bodies verbatim. This unblocksstats/progression/profilenext — they all share the accessor.server.py: 7,880 → 7,845.Verification
pyflakesclean.pytest2401 passed — includingtest_progression_api, whoseserver._progression_contentpatch still works because the cache stayed put.GET /api/shop200 (drivesappstate.get_progression_content); buy400on bad body.npm run lint0; Codex 0 findings.🤖 Generated with Claude Code
Summary by CodeRabbit