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>
62 lines
2.9 KiB
Markdown
62 lines
2.9 KiB
Markdown
# 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`: confirms `data-cy` attributes on all setup form fields
|
|
- `src/pages/EditMonitor.vue`: confirms `data-testid` on friendly-name, url, save-button
|
|
- `src/pages/Details.vue`: confirms `data-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):
|
|
```javascript
|
|
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
|