Live testing against the real site found MassPrice's login is behind hCaptcha, which silently blocks fully automated username/password login outright (the form never submits) — no selector fix could work around this. Also fixed the broken _is_logged_out() heuristic: an unauthenticated visit to /Rule/List redirects to the public marketing homepage, not a /login URL, so run_rule/list_rules were silently scraping the wrong page instead of erroring. New flow: a Session page lets the user start a headless-but-CDP-exposed Chromium instance, log in themselves via chrome://inspect (solving the captcha as a real click), then capture that browser's cookies into the same auth_state.json scheduled runs already use. Required a socat proxy in the container image, since Chromium's debug port binds loopback-only regardless of --remote-debugging-address (confirmed by live testing), unreachable through Docker's port mapping without it. All Playwright objects for this now live on one dedicated thread (automation.py's _debug_worker), since the sync API isn't safe to call across the arbitrary threads gunicorn's gthread workers hand out per request. Dashboard now shows a banner when the latest run failed specifically due to a missing/expired session, rather than just looking like an empty rule list. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H6TgffxTvYhqxykAbVQg2v
4.5 KiB
| name | description |
|---|---|
| deploy-massprice | Use when deploying MassPrice Scheduler, restarting the massprice container on Unraid, confirming a deploy landed, logging into MassPrice via the Session page, or troubleshooting its scheduled-rule automation. |
Deployment
Target: Unraid server, container path /mnt/user/appdata/massprice,
built from Dockerfile/docker-compose.yml in this repo. Container name
massprice, port 5057 (overridable via HOST_PORT — 5056 was
already taken by arr-summary, despite its own docs saying 5055) →
container port 5000. Also exposes DEBUG_PORT (default 9222) for the
Chrome-remote-debugging login flow — see below.
Deploy mechanism: Forgejo push-to-deploy, the same pattern as
arr-summary, card-grader, lunch-notifier, n64-tracker — see
arr-summary's deploy-arr-summary skill or card-grader's CLAUDE.md
for the full runner mechanics. Push to main on the forgejo remote
(https://git.hippofam.com/ninja_hippo/massprice.git) triggers
.forgejo/workflows/deploy.yml, which syncs into
/mnt/user/appdata/massprice (excluding .git, .env, data/) and
runs docker compose up -d --build.
Restarting the container manually: use Compose, not the Unraid Docker UI — same reasoning as the other projects (every deploy recreates the container with a new Docker ID; Unraid's UI caches the old one). From the Unraid terminal:
cd /mnt/user/appdata/massprice && docker compose restart
docker compose up -d --force-recreate for a guaranteed-clean recreate;
docker ps --filter name=massprice to check real state.
Confirming a deploy landed: the footer renders
v<APP_VERSION> · <APP_VERSION_DATE> from constants near the top of
app.py. Bump them every commit.
First deploy checklist
- Create
/mnt/user/appdata/masspriceon Unraid and a real.envthere (copy.env.example, fill inLOGIN_PASSWORD,SECRET_KEY,HOST_PORT,DEBUG_PORT,TZ). - First
docker compose up -d --build— confirm the container starts and/loginresponds onHOST_PORT. - Log into the webui, go to the Session page, and follow its
instructions: click "Start Login Session", connect your own Chrome to
<unraid-ip>:<DEBUG_PORT>viachrome://inspect, log in (solving the hCaptcha yourself — this cannot be automated, seeCLAUDE.md), then click "Capture Session" back in the webui. - Click "Refresh Rules" on the Dashboard — confirms the saved session actually works and pulls the real rule list.
- Set up at least one schedule and use "Run Now" once to confirm a
click actually lands — cross-check by looking at MassPrice's own
Activity Log (
https://massprice.tcgplayer.com/Activity/List) for a fresh timestamp on that rule. - Only after step 5 succeeds, go to each existing rule on massprice.tcgplayer.com (three-dot menu → Edit Schedule) and set Status to Inactive, so native scheduling stops double-triggering runs and this tool becomes the sole source of scheduled runs.
Persistent state, never touched by deploys
.env holds LOGIN_PASSWORD and SECRET_KEY. data/ (bind-mounted to
/data) holds schedules.json (the schedules set from the webui),
auth_state.json (the saved MassPrice browser session captured via the
Session page — losing this just costs one re-login, not data),
run_history.json, and rules_cache.json. Both are excluded from the
deploy rsync (which runs --delete) and from git.
If scheduled runs stop working
Check, in order:
- Dashboard banner / Activity page — a "session expired or missing" message means go log in again via the Session page. "rule id not found" means a rule was renamed/deleted on MassPrice — click "Refresh Rules".
- Is the container still running —
docker ps --filter name=massprice— a Chromium crash inside the container (rare, but possible ifshm_sizeever gets dropped fromdocker-compose.yml) would show as the container restarting. - Timezone —
TZin.envcontrols what "6:00 AM" means for every schedule; confirm it matches what the user actually expects before assuming a schedule itself is wrong. - Session capture stuck at "Still not logged in" — the debug
session's page needs to actually be on
/Rule/Listor somewhere under/Ruleafter login for the capture check to pass; if the inspected tab is still sitting on the marketing homepage or the OAuth login page, finish clicking through to the dashboard/rules first.