8da59cff22
Phase kuma M1 impl: resolves the 2026-05-28 DEFERRED uptime-kuma create-a-monitor item. Approach: Playwright (option b) — python-socketio not in cc-ci Nix env; Playwright handles Socket.IO transparently via the real browser. Selectors confirmed in 2.2.1 compiled bundle (data-cy setup wizard + data-testid monitor form/status badge). Test flow (test_monitor_wizard_and_probe): 1. Setup wizard: admin create via data-cy form → auto-login → /dashboard 2. Create self-probe monitor (https://{live_app}/) → wait ≤90s for "Up" badge 3. Heartbeat table row check: isFirstBeat=important, row has real datetime stamp 4. Negative: dead-port monitor (http://127.0.0.1:19999/dead) → wait ≤60s for "Down" All waits are bounded poll with page.wait_for_function/wait_for_url/wait_for_selector. Admin password: 64-char UUID hex, never printed/logged. Also: DECISIONS.md records Playwright choice; phase state files bootstrapped. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.9 KiB
JOURNAL — phase kuma (uptime-kuma create-a-monitor functional test)
Design rationale, investigations, and dead-ends. Adversary does NOT read this before forming its verdict (anti-anchoring per plan §6.1). See STATUS-kuma.md for claim context.
2026-06-11 — Approach selection: Playwright over python-socketio
Context: The phase plan offers two choices:
- (a) python-socketio client speaking Socket.IO events directly
- (b) Playwright driving the real browser UI
Investigation: Checked the cc-ci Nix Python environment:
/nix/store/x188l04r3gfkh18gy1dpf05fv3kkrgs7-python3-3.12.8-env/lib/python3.12/site-packages/
→ greenlet, playwright 1.50.0, pytest 8.3.3, pyee, packaging, pluggy, iniconfig
→ NO socketio, NO websocket-client, NO aiohttp, NO requests
python-socketio would need a nix/cc-ci.nix addition + nixos-rebuild switch on cc-ci.
Playwright is already present. Chose option (b): no Nix changes, faster to ship.
Selector research: Inspected uptime-kuma 2.2.1 source files in the Docker image:
src/pages/Setup.vue: confirmsdata-cyattributes on all setup form fieldssrc/pages/EditMonitor.vue: confirmsdata-testidon friendly-name, url, save-buttonsrc/pages/Details.vue: confirmsdata-testid="monitor-status"on status badge- Compiled bundle
dist/assets/index-D_mnxLA0.js: grep confirms all target attributes
Heartbeat "important" logic: Checked server/model/monitor.js line 1420:
// * ? -> ANY STATUS = important [isFirstBeat]
The server marks the first heartbeat as important=true, so it WILL appear in the
important-heartbeat table immediately after the first probe. This means the table row
check is a reliable proof of real probe execution.
Status text: From src/mixins/socket.js line 755 (statusList computed):
text: this.$t("Up"), // UP=1
text: this.$t("Down"), // DOWN=0
English locale: "Up" (capital U, lowercase p) and "Down". Used these exact strings in
the _wait_for_status assertions.
URL routing: src/router.js uses createWebHistory() (history mode, not hash mode).
Routes: / → Entry.vue → redirects to /dashboard; /add → EditMonitor.vue;
/dashboard/:id → Details.vue. So page.goto(f"{base}/add") reliably opens the monitor
form directly.
Negative test choice: http://127.0.0.1:19999/dead:
- Inside the container, port 19999 is unused → OS returns ECONNREFUSED instantly
- Connection-refused causes uptime-kuma to mark the monitor DOWN immediately (no timeout wait)
- This proves the probe engine makes real outbound calls (not a stub)
- Included — fits runtime budget easily (~5 s for DOWN detection)
Runtime budget analysis:
- Setup wizard + login: ~10 s
- Create monitor 1 + wait UP: ~15-30 s (first probe immediate, but socket roundtrip)
- Create monitor 2 + wait DOWN: ~10 s (ECONNREFUSED is fast)
- Overhead: ~5 s
- Total estimate: ~40-55 s — well within ≤90 s target