Fixes#1616. Supersedes the soften-and-track approach from #1172 (now
closed).
## What
Architectural fix for the slide-over close path so it no longer
transitions through a `focused-but-hidden` state. Chromium-headless
cannot deterministically order focus/blur events when `panel.hidden =
true` happens in the same microtask as a delegated table re-render —
root cause of the flake family that was blocking ~8 unrelated PRs at a
time and flipping master CI ~50%.
## How (three changes per #1616 acceptance criteria)
1. **Panel detach on close.** `open()` attaches panel + backdrop to
`<body>`; `close()` removes them. `isOpen()` is now a boolean flag
(`panelOpen`) instead of `(!panel.hidden)` — the closed panel literally
does not exist in the document tree, so there is no focused-but-hidden
window.
2. **Focus restore by `data-value` lookup at restore time.** Sync
`tr.focus()` BEFORE detach. If `document.activeElement !== tr` after the
sync call, attach a one-shot `MutationObserver` on the table's `tbody`;
on a matching row re-attach, call `.focus()` once and `disconnect()`.
Observer has a 2s timeout fallback so it doesn't leak when the row is
genuinely gone.
3. **Permanent CI flake-gate.** New step in
`.github/workflows/deploy.yml`: runs `test-slideover-1056-e2e.js` 20
consecutive times. Any single non-zero exit aborts. If this step ever
turns red post-merge, the focused-but-hidden state has crept back in.
## Hard-asserted (no more soft-warn)
All three deferred assertions are now `assert(...)`:
- `focus-restore@800: Escape returns focus to originating row`
- `focus-restore@800: X-button click returns focus to originating row`
- `resize@800→1440 nodes: cleanup releases panel, backdrop, scroll-lock,
focus` (focusRestored portion)
## Commits
- `fce39304` — RED: un-skip the two soft-skipped assertions
- `cead78df` — GREEN: architectural fix (detach + MutationObserver)
- `4f6d5c47` — CI: permanent `--repeat-each=20` flake-gate
## Verification
The 20-run gate is the verification. Watch the new `Slide-over E2E
flake-gate (#1616, --repeat-each=20)` step on this PR's CI; merge only
if it passes.
## Why this is the right fix
Five prior patches (`7891b70`, `366af4f`, `36ebecc`, `df5397f`,
`d681505`) all targeted the focus call ordering and all flaked in CI
Chromium-headless. The unfixable bit is "hidden-but-was-focused" —
Chromium reorders blur/focus across that transition
non-deterministically. Removing the transition (detach instead of hide)
removes the race entirely.
Closes#1616. Closes#1172 (already closed).
---------
Co-authored-by: openclaw-bot <bot@openclaw>
Co-authored-by: CoreScope bot <bot@corescope.local>
Co-authored-by: clawbot <bot@clawbot.local>
Fixes#1614
## Problem
`window.getTileUrl()` in `public/roles.js` returned the active
provider's `url` property as-is. After #1533 added carto/osm/stamen
providers with lazy-resolved URLs (`url: function () { ... }`), the
helper returned the function itself instead of a URL template string.
Callers handed that function to `L.tileLayer()`, which stringified the
source as the template — every tile 404'd, the map went blank, and
Leaflet logged no error.
User-visible impact: node-detail inset map and analytics minimap
rendered zero tiles whenever a function-`url` provider was the active
dark-theme pick.
## Root cause
`public/roles.js:365-381` — `return p.url || p.baseUrl;` with no `typeof
=== 'function'` invocation. The provider registry in
`public/map-tile-providers.js:45-53` declares almost every provider with
`url: function() { ... }` for lazy config resolution (cartocdn domain,
OSM provider/token, Stamen API key).
## Fix
One-line change in the consumer (`getTileUrl()`). Invoke `url` /
`baseUrl` if it's a function; otherwise return it verbatim.
`map-tile-providers.js` is not touched — it remains the source of truth
for the lazy-resolver pattern.
```js
var u = p.url || p.baseUrl;
return (typeof u === 'function') ? u() : u;
```
## Callers reviewed
| Caller | Disposition |
| --- | --- |
| `public/nodes.js:94` (`_applyTilesToNodeMap`) | Routes through
`window.getTileUrl()` → fixed transitively |
| `public/analytics.js:2055` (`L.tileLayer(getTileUrl(), …)`) | Routes
through `getTileUrl()` → fixed transitively |
| No other `getTileUrl()` callers | `grep -n "getTileUrl\b" public/*.js`
confirms only the two above |
## Commits (red → green)
- `a2b23392` — `test(#1614): red — getTileUrl() must return string, not
function` — adds `test-issue-1614-tile-url-function.js`. Verified to
fail on assertion (not build error) before the fix landed; passes after.
- `26fcacd1` — `fix(#1614): invoke provider url() when it's a function`
— minimal one-line fix in `roles.js` plus wiring the new test into
`deploy.yml` and `test-all.sh`.
## Tests
Unit test asserts the public contract from three angles so any
regression of either branch fails CI:
1. Dark + `url: function()` → returns a string template containing
`{z}/{x}/{y}`.
2. Dark + `url: 'https://…'` → returns the string verbatim (no
double-invoke).
3. Dark + `baseUrl: function()` fallback → also invoked, also returns a
string.
Wired into CI via `.github/workflows/deploy.yml` and `test-all.sh`.
## E2E coverage
Skipped intentionally. The existing Playwright harness
(`test-e2e-playwright.js`) runs against a deployed BASE_URL and is not
invoked from the Go CI workflow (`deploy.yml`). Adding a new E2E flow
there would require standing up a leaflet/tile-loading harness for a
single one-line regression. The unit test covers the exact
`getTileUrl()` contract that this bug violates and would have caught it;
if reviewers want a Playwright assertion later we can add it as a
follow-up. Manual verification was performed against staging
(`http://analyzer-stg.00id.net/#/nodes/...`).
## Preflight
`bash ~/.openclaw/skills/pr-preflight/scripts/run-all.sh origin/master`
— clean (all gates pass, PII clean, red commit verified).
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
## Summary
Fixes#1606 — frontend `public/nodes.js` issued a single `?limit=5000`
fetch to `/api/nodes` and trusted the response as the complete node set.
After PR #1540 (v3.8.3) clamped `/api/nodes` `?limit` to 500 as a DoS
guard, that single fetch silently truncated to the top 500 rows by
`last_seen DESC`. On the reporter's 2313-node deployment, **78% of nodes
(1813) were invisible** in the Nodes page, with no UI indication
anything was missing.
Replaces the single fetch in `loadNodes()` with a pagination loop driven
by `data.total` from the first response. Stops when `_allNodes.length >=
total`, when the server returns a short page, or at a 10 000-row safety
cap. `counts` is taken from the first response and refreshed on each
subsequent page (last writer wins; the server returns the same `counts`
payload each call).
Scope is deliberately narrow per the (munger) finding in the triage
comment: the three sibling call sites (`analytics.js:2080,2817`,
`packets.js:791`) are **NOT** touched here. They get their own
follow-up.
## Repro
```bash
curl -s "https://analyzer.marwoj.net/api/nodes?limit=5000" | jq '{nodes_len: (.nodes | length), total}'
# Before fix on >500-node deployment:
# { "nodes_len": 500, "total": 2313 } ← frontend silently displays only 500
```
## Before / after evidence
Unit test `test-issue-1606-pagination.js` drives `loadNodes()` against a
mocked `api()` exposing 1200 fixture nodes with a 500-per-page server
cap (mirrors the real `/api/nodes` clamp).
| | `_allNodes.length` | `data.total` |
|---|---:|---:|
| Before (single fetch) | **500** | 1200 |
| After (pagination loop) | **1200** | 1200 |
Red commit: `700a5cc4` (test asserts `_allNodes.length === data.total`,
fails 500 ≠ 1200).
Green commit: `6d51da45` (pagination loop, test passes).
All 611 tests in `test-frontend-helpers.js` continue to pass — the
existing nodes.js WS-handler runtime tests are unaffected.
## Browser verified
Mocked-API unit test only — staging currently has <500 nodes so the bug
isn't reproducible there. The reporter's deployment
(`analyzer.marwoj.net`, 2313 nodes) is where the visible regression
occurs. The unit test reproduces the exact failure mode against a
controllable fixture.
## E2E assertion added
`test-issue-1606-pagination.js:170` — `assert.strictEqual(all.length,
env.fixtureTotal, ...)`
## Files changed
- `public/nodes.js` — `loadNodes()` single fetch → pagination loop
- `test-issue-1606-pagination.js` — new regression test (sandboxed
nodes.js + mock api)
## Out of scope (deferred to follow-up)
Per triage's (munger) note, these three siblings have the same
single-fetch bug and need their own focused PR:
- `public/analytics.js:2080` (`limit=10000`)
- `public/analytics.js:2817` (`limit=10000`)
- `public/packets.js:791` (`limit=2000`)
Closes#1606
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
fix for the focus-restore@800 E2E test that's currently failing on
master (see runs 26990436988, 26986419081)
Chromium headless is notorious for dropping synchronous or rAF-based
focus restores when elements are hidden. By manually blurring the active
element before hiding the panel, and staggering the focus restore with a
setTimeout macrotask after the rAF, we ensure the focus call lands after
the browser has completed all implicit focus resets and event handlers.
Furthermore, dynamically evaluating the focus resolver directly inside
the deferred focus attempt prevents the target element from becoming
stale if a live WebSocket packet triggers a background table re-render
in the intervening milliseconds.
## Summary
Partial fix for #1599 — replay from packets sidebar no longer freezes
the live map.
Clicking **Replay** on a packets-page row wrote the packet to
`sessionStorage['replay-packet']` and navigated to `/#/live`. On init,
`live.js` called `vcrPause()` to silence live WS traffic during the
replay. But `vcrPause()` sets `VCR.mode = 'PAUSED'`, and
`renderAnimations()` gates `anim.progress` advancement on `!isPaused` —
so the replayed animation never advanced and the map appeared frozen.
## Fix
Introduce a module-level `suppressLive` flag dedicated to muting live WS
traffic without entering `PAUSED`. The WS handler's `LIVE` branch honors
the flag (still ticking `updateTimeline` so the UI keeps reflecting
traffic). The replay handoff sets the flag for ~12 s — long enough for
the animation to play out — then clears it.
Files changed:
- `public/live.js` — module flag (`~145`), replay handoff (`~1502`), WS
LIVE branch (`~897`)
- `test-issue-1599-replay-freeze-e2e.js` — new Playwright E2E (seeds
`sessionStorage['replay-packet']`, asserts `activeAnimations` drains
after the handoff)
- `.github/workflows/deploy.yml` — wire the new E2E into the deploy E2E
block
## TDD trail
| Commit | Role |
| --- | --- |
| `8a0add00` | Red — failing E2E (asserts the queued animation drains;
pre-fix it never does → `FAIL: activeAnimations did NOT drain after
replay handoff (count=1) — replay freeze regression`) |
| `8069210d` | Green — `suppressLive` flag replaces `vcrPause()` in the
handoff |
| `c2a84a3e` | CI wiring |
Locally reproduced both states against the e2e-fixture DB (Chromium via
`CHROMIUM_PATH=/usr/bin/chromium`):
- HEAD red commit: `2 pass, 1 fail` (assertion-shaped, not compile)
- HEAD green commit: `3 pass, 0 fail`
Browser verified: local Chromium against `corescope-server -port 13581
-db /tmp/e2e-fixture.db -public public` — `replay-packet` key is
consumed by the init path, animation queues, and drains post-fix.
E2E assertion added: `test-issue-1599-replay-freeze-e2e.js:111`
(`activeAnimations drained to 0`).
## What this PR does NOT do
The reporter explicitly called out a second, separable problem on the
same issue: `renderPacketTree(packets, true)` runs with `isReplay =
true`, which skips `addFeedItem` (`public/live.js:3155`), so the
bottom-left feed shows "Waiting for packets…" even once the map
animates. That is a UX decision (should the replayed packet appear in
the feed?) and is intentionally **not** addressed here. Leaving #1599
open so the operator can decide.
Hence: **"Partial fix for #1599"** — no `Fixes #` keyword.
## Preflight
`bash ~/.openclaw/skills/pr-preflight/scripts/run-all.sh origin/master`
→ all hard gates ✅, no warnings.
---------
Co-authored-by: corescope-bot <bot@corescope>
## Summary
Build the distance analytics index lazily on the first
`/api/analytics/distance` request instead of eagerly inside `Load()`
(and its background-load chunked merge). Per the triage Fix path on the
issue:
- Eager startup build removed from `Load()` and from
`loadAllPacketsBackground()`'s post-merge pass.
- First request returns `202 Accepted` + `Retry-After: 5` and kicks off
the build in a background goroutine, gated by `sync.Once` so concurrent
first-window requests all observe 202 (single build, not N parallel
O(n²) computations).
- Once built, subsequent requests fall through to the existing
analytics-recomputer / TTL cache and serve 200 as before.
- Debounced rebuild policy: refire only when `Δobs > 5%` since last
build OR `>5 min` elapsed, whichever is more restrictive. Background
loader also resets the gate so the next request rebuilds against the
larger dataset.
Effect: operators who never visit distance analytics no longer pay the
O(n²) construction at startup. Acceptance criteria (a) no startup build,
(b) first request triggers build, (c) concurrent in-flight requests get
202 are encoded as failing-first tests.
## Red → green
- Red: `bc947ad1` — 3 assertion failures (`expected ... empty, got 3`,
`expected 202, got 200`, `expected all 10 ... got 0`).
- Green: `5264b68a` — production change makes them pass, no other tests
regress.
## Files changed
- `cmd/server/store.go` — lazy-build state
(`distLazyMu`/`Once`/`Built`/`Building`/`LastBuilt`/`LastObs`),
`TriggerDistanceIndexBuild`, `DistanceIndexBuilt`,
`DistanceIndexBuilding`; eager `buildDistanceIndex` calls in `Load()`
post-pass and chunked-background-load post-pass removed (Once reset
instead so the next request rebuilds against the full dataset).
- `cmd/server/routes.go` — `/api/analytics/distance` returns 202 +
`Retry-After` until built.
- `cmd/server/distance_lazy_index_test.go` — new tests (the three triage
acceptance criteria).
- `cmd/server/coverage_test.go`, `cmd/server/parity_test.go`,
`cmd/server/routes_test.go`, `cmd/server/hop_disambig_e2e_test.go` —
pre-warm the index via `TriggerDistanceIndexBuild()` +
`DistanceIndexBuilt()` poll where the test asserts the 200 JSON shape.
## Perf justification
Startup cost on a 500K-obs / 2K-node dataset: previously O(n²) hop scan
during `Load()` post-pass and again during the background-load merge —
measured at 10–20s in `specs/startup-audit.md`. New code: zero work at
startup, the same O(n²) work runs at most once per HTTP request cycle
(and only when the index is stale per debounce policy). Cold-path
concurrency is bounded by `sync.Once`, so N parallel first-window
requests never produce N parallel builds.
## Scope
No config field added (debounce thresholds are hardcoded constants per
the triage Fix path — `5%` / `5min`). No public API signature changes.
No DB-side migration. Tests cover the lazy invariant, the
202+Retry-After contract, and concurrent first-request behavior.
Closes#1011
---------
Co-authored-by: Kpa-clawbot <bot@corescope.local>
## Problem
`/analytics` Hash Usage Matrix 1-byte view excluded repeaters configured
for 2- or 3-byte hash prefixes. In MeshCore, 1-byte path-matching is a
first-byte equality check, so any packet routed by 1-byte hash collides
on that first byte regardless of the downstream repeater's configured
prefix size. Omitting multi-byte prefix repeaters under-reports real
conflicts in the 1-byte hash space.
## Fix
**Data layer — `cmd/server/store.go` (`computeHashCollisions`,
~L7907-L7918 before, L7907-L7941 after):**
Before — `one_byte_cells` was populated only from `prefixMap`, which
only contained repeaters with `hash_size == 1`:
```go
if bytes == 1 {
oneByteCells = make(map[string][]collisionNode)
for i := 0; i < 256; i++ {
hex := strings.ToUpper(fmt.Sprintf("%02x", i))
oneByteCells[hex] = prefixMap[hex]
if oneByteCells[hex] == nil {
oneByteCells[hex] = make([]collisionNode, 0)
}
}
} else if bytes == 2 { ... }
```
After — additionally project all `hash_size in {2,3}` repeaters to their
first byte:
```go
if bytes == 1 {
// ... (same baseline population) ...
for _, cn := range allCNodes {
if cn.Role != "repeater" { continue }
if cn.HashSize != 2 && cn.HashSize != 3 { continue }
if len(cn.PublicKey) < 2 { continue }
hex := strings.ToUpper(cn.PublicKey[:2])
if _, ok := oneByteCells[hex]; !ok { continue }
oneByteCells[hex] = append(oneByteCells[hex], cn)
}
}
```
The 2-byte view's bucketing is unchanged — that view continues to count
only repeaters configured for 2-byte prefixes (those semantics differ).
**UI — `public/analytics.js` L1459:** clarified the 1-byte view
description so the inclusion of multi-byte prefix repeaters is explicit.
## API shape
No response-shape change. `one_byte_cells[HEX]` is still
`[]collisionNode`; only the contents now include 2/3-byte prefix
repeaters in the appropriate first-byte buckets. The existing frontend
decoder is unaffected.
## Tests
-
`cmd/server/routes_test.go::TestHashCollisionsOneByteIncludesMultiBytePrefixRepeaters`
— seeds three repeaters with first byte `CC` configured for 1/2/3-byte
prefixes plus an unrelated `DD` repeater, asserts all three appear in
`one_byte_cells["CC"]`, and that the 2-byte view's `nodes_for_byte` is
unchanged.
Red commit `278bdf8d` (test only) fails on assertion ("got 1, want 3");
green commit `9127ea4e` passes.
## Preflight
`bash ~/.openclaw/skills/pr-preflight/scripts/run-all.sh origin/master`
→ clean.
Closes#1218
---------
Co-authored-by: clawbot <bot@corescope>
- Eliminated extra space to the right of the map filters.
- Made the map filters and mesh live a single line with a divider
- Resized the input and dropdowns in the map filters so they meet WCAG
2.5.5 by being at least 44px high, but appearing 30px high
- Turned the filters cog and the fullscreen button into native leaflet
icons that are large enough to meet WCAV 2.5.5 compliance
- Increased the size of the zoom buttons to meet WCAG 2.5.5 compliance
on both the live and map pages
- If the top nav bar is pinned, it won't disappear during fullscreen but
if it isn't pinned, it will disappear with everything else.
- The cog and full screen button change color to show they're active
Final Outcome in 4k
<img width="2878" height="1406" alt="image"
src="https://github.com/user-attachments/assets/28db46a2-f1bb-4d9c-9d77-30c444b4ef3d"
/>
Final Outcome in 1080p
<img width="1920" height="1080" alt="image"
src="https://github.com/user-attachments/assets/120be8ec-0279-40fc-925a-243e9c0bcc1c"
/>
## Problem
Node detail's bimodal-clock warning showed only `⚠️ N of last M adverts
had nonsense timestamps (likely RTC reset)` — no way to tell which
packets, no way to verify the heuristic, no way to drill in.
## Fix
Additive, two-sides:
**Backend** (`cmd/server/clock_skew.go`)
- New type `BadSample { Hash, AdvertTS, SkewSec }`.
- New field `NodeClockSkew.RecentBadSamples []BadSample` (`omitempty`).
- Populated from the **same** bimodal-bad classification pass that
produces `RecentBadSampleCount` — no heuristic change. `tsSkewPair`
carries `hash` + `advertTS` so the classifier can record per-sample
evidence without a second walk; drift code is unaffected (reads only
`ts`/`skew`).
**Frontend** (`public/nodes.js`)
- `bimodalWarning` preserves the existing count summary line, then
renders a `<ul>` of bad samples: each `<li>` is `<a
href="#/packets/HASH">hash[:8]</a> → formatTimestamp(advertTS)` with ISO
tooltip. Defensive `Array.isArray` so older API responses still render
the summary alone.
## TDD
- **Red:**
`cmd/server/clock_skew_issue1094_test.go::TestIssue1094_RecentBadSamples_ExposesHashAndTimestamp`
— seeds 3 healthy + 2 bimodal-bad adverts, asserts `RecentBadSamples`
has length 2 with the expected hashes and advert timestamps. Fails on
the assertion (`len = 0, want 2`) with the stub-only commit.
- **Green:** classifier populates the slice; existing #1285 and bimodal
tests stay green.
- Red commit: `ed501f4b`
- Green commit: `54305b06`
## Cross-stack
Backend + frontend ship together (`cross-stack: justified` commit). API
stays backward compatible (`omitempty` server, `Array.isArray` client)
but the feature only lights up with both halves present.
## Preflight
Clean — PII, branch scope, red-commit, CSS vars, XSS sinks, migrations,
fixture coverage all pass.
## Acceptance
- [x] Warning lists specific packet hashes
- [x] Each hash links to `#/packets/<hash>`
- [x] Bad advert timestamp shown next to the hash
- [x] Pattern is reusable — `BadSample` is a clean shape any future
heuristic that flags specific packets can adopt
Fixes#1094
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
Fixes#1170.
## What
1. **Doc comment** on `writeStatsAtomic` (`cmd/ingestor/stats_file.go`)
spelling out the two-sided symlink story:
- tmp side (`path+".tmp"`): protected by `O_NOFOLLOW` (existing
behavior, already noted).
- rename side (`path` itself): NOT protected by `O_NOFOLLOW`; instead
`os.Rename` semantics are relied upon — rename atomically replaces any
existing entry at `path` (including a symlink) with the new regular
file. The symlink target is never written through because all writes
happened to the unrelated tmp file before rename.
2. **Regression guardrail test**
`TestWriteStatsAtomic_SymlinkAtDestIsReplaced` in
`cmd/ingestor/stats_file_test.go` that pre-plants a symlink at the
destination path pointing to an unrelated target file, calls
`writeStatsAtomic`, and asserts:
- (a) `os.Lstat(path).Mode()&os.ModeSymlink == 0` (post-write path is a
regular file, not a symlink)
- (b) the original symlink target's sentinel bytes are unchanged.
If a future refactor swaps `os.Rename` for a
destination-symlink-following primitive (e.g. `open(path, O_WRONLY)`
without `O_NOFOLLOW`, or a copy-then-truncate), the test fails loudly.
## TDD note (red-commit exemption)
The current `writeStatsAtomic` ALREADY satisfies the new test's
assertions — `os.Rename` does the right thing today. Per the fix-issue
skill's exemption for pure-documentation / guardrail tests on
already-correct behavior, no fabricated red commit was constructed; the
test stands as a pinning regression guard. The two commits are
therefore: (1) test addition, (2) doc comment.
## Scope
- `cmd/ingestor/stats_file.go` — doc comment only
- `cmd/ingestor/stats_file_test.go` — one new test function
No production behavior change. No public API change. No new
dependencies. No CI workflow changes. `O_NOFOLLOW` and the existing
tmp-side behavior are untouched.
## Preflight
All hard gates pass (PII, branch scope, red commit, CSS vars,
LIKE-on-JSON, sync/async migration, XSS sinks). No warnings.
---------
Co-authored-by: meshcore-bot <bot@meshcore.local>
## What
Mock `/api/nodes/search` at the Playwright level in
`test-home-coverage-e2e.js` so the home-coverage E2E search-suggestions
step renders deterministically.
## Why
The `step('search input renders suggestions for a 1-char query', …)`
block was previously softened to a no-op (`pickAnyPubkey` + a
`console.log('SKIP …')`) because the live fetch path flakes on cold CI:
`home.js`'s `setupSearch` wraps `/api/nodes/search` in a try/catch that
swallows network errors, so the dropdown's `.open` class never gets
added and the `waitForSelector('.home-suggest.open')` hung.
Per the triage fix path on #1313, install
`page.route('**/api/nodes/search**', …)` to fulfill a deterministic JSON
body and restore the real assertions.
## Red → Green
- **Red commit `d062b35`** — adds the assertion (type into
`#homeSearch`, wait for `.home-suggest.open`, assert ≥ 1 `.suggest-item`
AND that `HomeFlakeFix-1313` is among the rendered names) **without**
the `page.route` mock. The live fixture nodes don't include that
sentinel name → `assert(names.includes(FIXTURE_NAME))` fires
deterministically. This proves the test is meaningful and reaches the
assertion (no build/import error).
- **Green commit `9fc265a`** — installs the `page.route` handler
returning `{ nodes: [{ public_key: <real fixture pubkey>, name:
'HomeFlakeFix-1313', role: 'companion' }] }`. The dropdown renders the
sentinel name → assertion passes. A real fixture pubkey is reused (via
`pickAnyPubkey`) so downstream steps that hit `/api/nodes/<pk>/health`
still see a valid backend response.
E2E assertion added: `test-home-coverage-e2e.js:115-133`.
## Scope
Test-only. No production code changed. Bonus suggestion in the issue
body about adding a visible error state to `home.js`'s search catch
branch is out of scope here — file separately if desired.
Closes#1313
---------
Co-authored-by: mc-bot <bot@openclaw.local>
Partial fix for #1402
## Summary
Re-fix two of the four #1402 regressions on mobile after `#1452`
silently reverted the prior fix (`6ec08acb`). Two predicate flips in
`public/gesture-hints.js` + extended E2E coverage to prevent another
silent revert.
This PR is intentionally **scoped to Bug 2 and Bug 4 only**. Bug 1 and
Bug 3 were also dropped by `#1452` and are NOT restored here — `#1402`
remains open for the rest.
## Changes
- `public/gesture-hints.js` (edge-drawer): `window.innerWidth > 768` →
`window.innerWidth <= 768`. The edge-swipe drawer is the MOBILE layout's
nav per #1064/#1184; `nav-drawer.js` `NARROW_MAX=768` (inclusive —
narrow when width <= NARROW_MAX). Above 768 the sidebar is persistent,
no edge-swipe is needed.
- `public/gesture-hints.js` (row-swipe): widen route filter from
`/^#\/(packets|nodes)/` to `/^#\/(packets|nodes|channels|observers)/`.
Channels and observers also render swipable row tables.
- `public/gesture-hints.js`: expose read-only
`window.__gestureHintsDefs` test hook (frozen) for direct predicate
probes (avoids race with render path).
- `test-gesture-hints-1065-e2e.js`: add assertions (i)+(j) at vw=393 —
edge-drawer relevant on `/#/home`, row-swipe relevant on `/#/channels`;
(k) negative-direction gate at vw=1024 asserts `edge-drawer.relevant()
=== false` on desktop. Retarget (e) from 1024x800 → 393x800 to match the
corrected mobile-only gate.
## TDD
- Red commit: `1e7545d1` — test additions fail against current
production code (edge-drawer relevant returns false at vw=393, row-swipe
filter rejects /channels).
- Green commit: `6f844d5b` — predicate flips + route widening make both
assertions pass.
- Polish commit (round-1 fixes): boundary <= 768, doc-header refresh,
freeze the test hook, negative-direction gate (k), precondition
assertion on (i).
## Acceptance criteria from #1402
- [ ] Bug 1 (`window 'load'` rescheduler + `pointer: coarse` gate) —
dropped by #1452, NOT restored in this PR. Tracked in #1402.
- [x] Bug 2 (edge-drawer mobile-only) — fixed here.
- [ ] Bug 3 (pull-refresh touch-gate decoupling) — dropped by #1452, NOT
restored in this PR. Tracked in #1402.
- [x] Bug 4 (row-swipe widening → /channels + /observers) — fixed here.
- [x] E2E mutation gate: assertions (i)+(j)+(k) provably fail if either
predicate is reverted or re-broadened.
## Notes
- Silently reverted by #1452 — re-fix here, with regression gates so the
next reviewer of the next refactor will see the assertions fail rather
than the production behavior change unnoticed.
## Preflight
All gates pass (PII, branch scope, red commit, CSS vars, XSS sinks,
etc.).
---------
Co-authored-by: meshcore-bot <bot@meshcore.local>
Co-authored-by: fix-1166-bot <bot@corescope.local>
## Summary
Adds a sortable **First Seen** column to the Nodes table so users can
spot newly observed repeaters in their region (per the reporter's use
case).
Closes#1166
## Backend
`/api/nodes` already exposes `first_seen` per node via `db.scanNodeRow`
(sourced from the existing `nodes.first_seen` column — no schema
migration, no recomputation, no extra query cost). The red test pins
that contract.
## Frontend (`public/nodes.js`)
- New `<th data-sort-key="first_seen" data-sort-default="desc">First
Seen</th>` between Last Seen and Adverts.
- Cell renders via `renderNodeTimestampHtml(n.first_seen)` — same
relative-time + absolute-ISO `title=` tooltip as the Last Seen column.
Empty values render as `—`.
- `sortNodes` gains a `first_seen` branch with **empty-last** semantics:
nodes without a `first_seen` always sort to the bottom regardless of
asc/desc direction, so unknowns never clutter the top of the table.
- Empty-state `colspan` bumped 7 → 8.
## TDD
- **Red commit** `112442f4` — `test-issue-1166-first-seen-column.js` +
`cmd/server/first_seen_1166_test.go`. The backend half passes on red
(field already returned); 5 frontend assertions fail on assertions
(column header missing, sort branch missing, empty-last violated).
- **Green commit** `9274b36c` — only `public/nodes.js`. All 6 tests
pass.
Verified red is real-fail (assertion-shaped) by checking out the red
commit's `nodes.js` and re-running the test: 5 failures, all on
`assert.strictEqual`, none on parse/import.
## Test results
```
node test-issue-1166-first-seen-column.js → 6 passed, 0 failed
node test-frontend-helpers.js → 611 passed, 0 failed
go test ./cmd/server/... → ok (45.16s, all pass)
```
## Files changed
- `public/nodes.js` (+14 / −1)
- `test-issue-1166-first-seen-column.js` (new)
- `cmd/server/first_seen_1166_test.go` (new)
## Scope guardrails
- No schema migration.
- No new files outside the worktree's three allowed surfaces.
- No refactor of other Nodes columns.
- Empty cells handled in both render (em-dash) and sort (always last).
---------
Co-authored-by: fix-1166-bot <bot@corescope.local>
## Summary
Closes#1546. `/api/stats` reported
`{"backfilling":true,"backfillProgress":0}` on every fully-converged
server, and `X-CoreScope-Status: backfilling` was sent on every request.
Root cause: the `Store` had three atomic fields — `backfillComplete` /
`backfillTotal` / `backfillProcessed` — read by `handleStats` and
`backfillStatusMiddleware`, but **nothing ever wrote to them**. They are
leftovers from the server-side async backfill added in #612/#614. That
work moved to the **ingestor** in #1289 (server is now read-only) and
the writer `backfillResolvedPathsAsync` was deleted, orphaning the
readers. `backfillComplete.Load()` therefore always returned `false`, so
`backfilling := !false` was permanently `true`.
This is the leftover of an intentional architecture change, not an
unfinished feature — the server no longer does backfill by design, so
the correct fix is to delete the dead flag (per triage recommendation;
zero consumers).
## Changes
- `store.go` — drop the 3 dead atomic fields.
- `routes.go` — drop `backfillStatusMiddleware` (+ its registration) and
the backfill-progress computation in `handleStats`.
- `types.go` — drop `Backfilling` / `BackfillProgress` from
`StatsResponse`. **API change:** `/api/stats` no longer emits
`backfilling` / `backfillProgress`; the `X-CoreScope-Status` header is
removed. Verified no frontend or other consumer reads them.
- `resolved_index.go` — remove stale comment referencing the deleted
`backfillResolvedPathsAsync`.
## Test
Regression assertion added to `TestStatsEndpoint` (#1546): asserts the
response no longer carries `backfilling` / `backfillProgress` and that
`X-CoreScope-Status` is unset. Verified red→green — against pre-fix code
all three assertions fail; with the fix they pass. Full `cmd/server`
suite green locally.
## Out of scope
If a real server-side backfill/migration status indicator is wanted,
that's a new feature on top of the ingestor stats pipe — tracked
separately, not by reviving these dead fields.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Kpa-clawbot