Clicking Every Button in Qanat

What I did

Sent SIGSTOP to the server. It keeps the port open but answers nothing — a hang, not a crash. Waited 9 seconds, about four poll cycles.

What happened

connection label:   "connected"
body class:         book-editing results-open      (no server-down)
down banner shown:  false
still showing the old book numbers: true

Why it matters

No fetch() in the console sets a timeout, and there is no AbortController anywhere. A request to a hung server does not fail — it just never returns. So the "disconnected" path never runs, the banner never appears, and every panel keeps showing its last good snapshot as if it were live.

A hang is the more common failure in practice. A crashed server is obvious; a wedged one is not. And qanat can wedge itself — part one showed a job with no timeout holding a worker forever.

Credit: when the server is truly dead, this all works. I killed it and got body.server-down, "disconnected", and an honest banner: "qanat is not answering on this address. The console keeps the last thing it saw, so what is on screen may be old." That is good writing. The gap is only the hang.

What I did

Killed the server. Folded the graph (a normal thing to do while reading results). Then clicked RUN BACKTEST.

What happened

banner visible, graph open:   true
banner visible, graph folded: false
fold state saved to localStorage: "1"   (survives reload, forever)

modal open:            true
modal body length:     42 characters
warnbox element there: true
warnbox visible:       false
text the user sees:    ""

Why it matters

Two CSS rules combine badly.

The down banner lives inside <div class="view">, and .graph-folded .view { display: none } hides that whole container. The fold is saved to localStorage, so a user who folds the graph once loses the only explanation of a dead server on every visit after that.

Then body.server-down .warnbox { display: none } hides every warning box in the app while the server is down. The run form's failure path fills the modal with only a warnbox — so the modal opens, and it is empty. Same for the alpha editor and the source editor.

Net effect for that user: the server is dead, the console shows a small dot and one word, every panel shows old data, and clicking the main button opens a blank box.

What I did

Looked for #bt-list in the live DOM, because the error path writes to it.

What happened

document.getElementById('bt-list') -> null

the code that runs when /api/backtests fails:
  el('bt-list').innerHTML = '<div class="bt-empty bad">' + esc(e.message) + '</div>'

Why it matters

There is no id="bt-list" anywhere — not in index.html, not in the CSS. The runs-list panel it belonged to was removed, and this error path was left behind.

So when /api/backtests fails, the handler throws a TypeError on null.innerHTML, refresh() rejects, and the user sees no error at all. The results panel keeps drawing the last good run's equity curve and net figure, with nothing marking it stale. This repeats every 4 seconds for as long as the server is unhealthy.

What I did

Traced the progress poller, which is what lights up the graph while a backtest walks the window.

What happened

async function tick() {
  try {
    var r = await fetch('/api/backtest/progress');
    if (!r.ok) return;              // no reschedule
    p = await r.json();
  } catch (e) { return; }          // no reschedule
  ...
  schedule(p.running ? 120 : 2500);   // the only reschedule, at the very end
}

Why it matters

Both early returns skip the only line that schedules the next tick. So a single 500, or one dropped connection, kills live progress permanently.

What the user sees: the graph stops lighting up, the running total freezes on whatever rebalance it last saw, and the "run finished, show me the result" handoff never fires. They watch a stalled progress bar for the rest of a long backtest. Only a page reload brings it back.

What I did

Typed banana into the rebalance box, which is a free text field, and ran it.

What happened

POST /api/backtest  ->  500 Internal Server Error
body the user gets: "Internal Server Error"

server log:
  File "src/qanat/backtest.py", line 92, in dates
  File "src/qanat/retention.py", line 31, in parse_duration
  ValueError: retention must look like '7d' or '24h', got 'banana'

Why it matters

Two problems. First, /api/backtest only catches BacktestError. parse_duration raises a plain ValueError, so it escapes as a 500 and the user gets no explanation at all.

Second, even in the log the message is wrong for the situation. It says "retention must look like '7d'" — but the user typed a rebalance, not a retention policy. parse_duration lives in retention.py and is reused by the backtest for rebalance, purge and embargo, and its message never got updated. Anyone reading that log will go looking at the wrong setting.

What I did

Searched the whole front end for confirm( and prompt(.

What happened

confirm() calls in the console: 0
prompt()  calls in the console: 0

DELETE /api/alphas/{id}   — fires straight from the click handler
DELETE /api/stages/{id}   — same

Why it matters

The delete button sits in the same row as save, and one click removes an alpha from the project — the server rewrites qanat.yaml. "Remove this stage" is the same. No question is asked.

The console already has everything it needs to write a good confirmation: the graph payload carries the row count for every table, and the stage panel has already worked out which tables belong to that stage. It could ask "remove features, which holds 3 tables and 412,908 rows?" and instead it asks nothing.

It also throws away the server's answer. Deleting an alpha returns a helpful note — "the script is still on disk, and so is anything it wrote" — and the console never reads it.