Files
spencermandClaude Fable 5.1 39a4eb5213
ci / frontend (push) Successful in 30s
ci / server (push) Successful in 4m30s
ci / image (push) Successful in 35s
ci / e2e (push) Successful in 1m40s
Phase 4: Warehouse screen, pull table, shorts, MTRs and the upload pipeline
The Warehouse home with the numbers, the Open shorts table, the find bar and the five-column task board
(waiting, being pulled, on hold, pulled, released in the last 3 days) with buttons, hold reasons and drag.
Every role sees the warehouse stage on a packet as the WH pill and the line under it. The pull table on the
Materials tab: Pulled with auto-start, issued, location, heat with Enter to the next line, shorts with
receipts, N/A, MTR per line with a viewer. Send back to Clerical with a reason. Release to supervisor stays
blocked until every line is pulled or short and every pulled line has a heat.

Server: the heats_recorded precondition on WH_RELEASE, receive by custody, server-validated hold and short
reasons, the old packet history texts, GET /api/warehouse/board, cards with the warehouse stage and pull
counts. Uploads typed by content per kind (drawing, mtr, document, bom with XLSX and CSV), limits per kind,
optional ClamAV behind the clamav compose profile, a storage quota alert on the new notification_events
table (migration 0005) shown on the Admin Storage tab.

Tests: every warehouse action as every role, the release gate, the short-receive exception, the heat
pattern, upload sniffing and limits, the ClamAV path with a fake scanner, the quota alert; frontend board
and pull table tests; Playwright scenarios for the board and the pull flow. Verified on docker-1 in the CI
stack: 3557 server tests, 106 frontend tests, 17 Playwright scenarios. Docs updated; D5 closed.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
2026-10-16 17:13:31 -06:00

73 lines
2.4 KiB
Python

"""Housekeeping, nightly at 03:30 site time: prune the VISUAL change rows and gone cache rows, old job runs and
old claimed run requests. It never touches packets, the audit log or anything append-only. Then it checks the assets
storage against its warning threshold (assets.check_quota opens or resolves the alert)."""
from __future__ import annotations
from datetime import datetime, time
from ...domain import assets
from ...feed.config import FeedSettings
from . import Counts, JobContext, JobSpec, seconds_until
AT = time(3, 30)
CACHE_DAYS = 90
RUNS_DAYS = 180
REQUESTS_DAYS = 30
STEPS: tuple[tuple[str, str, int], ...] = (
("row_changes", "DELETE FROM visual_row_changes WHERE at < now() - make_interval(days => %s)", CACHE_DAYS),
(
"material_changes",
"DELETE FROM visual_material_changes WHERE at < now() - make_interval(days => %s)",
CACHE_DAYS,
),
(
"gone_rows",
"DELETE FROM visual_rows WHERE gone_batch IN"
" (SELECT id FROM visual_batches WHERE started_at < now() - make_interval(days => %s))",
CACHE_DAYS,
),
(
"gone_materials",
"DELETE FROM visual_materials WHERE gone_batch IN"
" (SELECT id FROM visual_batches WHERE started_at < now() - make_interval(days => %s))",
CACHE_DAYS,
),
(
"job_runs",
"DELETE FROM job_runs WHERE started_at < now() - make_interval(days => %s) AND status <> 'running'",
RUNS_DAYS,
),
(
"job_requests",
"DELETE FROM job_requests WHERE claimed_at IS NOT NULL AND claimed_at < now() - make_interval(days => %s)",
REQUESTS_DAYS,
),
)
def run(ctx: JobContext) -> Counts:
counts: Counts = {}
for name, sql, days in STEPS:
with ctx.conn.transaction():
counts[name] = ctx.conn.execute(sql, (days,)).rowcount
try:
usage = assets.check_quota(ctx.conn, ctx.settings)
except Exception as e: # the storage check never fails the pruning
ctx.log.exception("the storage quota check failed")
counts["quota_error"] = type(e).__name__
else:
counts["quota_pct"] = usage["pct"]
counts["quota_warn"] = usage["warn"]
if usage["alert"]:
counts["quota_alert"] = usage["alert"]
return counts
def cadence(_: FeedSettings, now_site: datetime) -> int:
return seconds_until(now_site, AT)
SPEC = JobSpec(name="housekeeping", run=run, cadence=cadence, pausable=False)