chore(deps): multibump rollup of 33 Dependabot bumps + release 0.3.8

[LivinTribunal]

Multibump rollup of all open pip + npm Dependabot PRs, reviewed dependacheck-style (investigate → test), plus version bump 0.3.7 → 0.3.8. 33 packages. Max tier D3 — all D3s verified safe by isolated old-vs-new execution.

Folds and supersedes: #497 #496 #500 #501 #505 #506 #518 #522 #523 #524 #525 #527 #528 #529 #530 #531 #532 #533 #534 #535 #536 #537 #538 #539 #540 #541 #542 #543 #544 #545 #546 #547 #548. Not included (GH Actions, review directly): #521 (actions/cache 5→6), #491 (actions/checkout 6→7).

Note: npm caret resolution landed some packages one notch above the Dependabot targets (e.g. lucide 1.24.0, rhf 7.81.0, typescript-eslint 8.63.0, prettier 3.9.5); review and changelog judgment were done against the landed versions.

Root pip (engine — critical blast radius)

Package	Change	Tier	Touches	Notes
croniter	6.2.2 → 6.2.3	D3	pyworkflow/utils/schedule.py:113,348 (croniter(), .get_next)	#232 zero-step range rejection changes constructor accept behavior at user-input call sites
filelock	3.29.4 → 3.29.7	D3	pyworkflow/storage/file.py (25× with FileLock(...))	#577: Unix .lock files persist after release
aws-durable-execution-sdk-python	1.5.0 → 1.7.0 (floor >=0.1.0→>=1.6.0)	D3	pyworkflow/aws/handler.py, aws/context.py, context/aws.py	suspend no longer surfaces as FAILED inside @durable_execution (#492); repo has zero real-SDK tests — see needs-judgment note below
click	8.4.1 → 8.4.2	D2	pyworkflow/cli/** (~290 symbol uses)	bugfix-only release; no fixed feature intersects our symbol set
pytest	9.0.3 → 9.1.1 (floor >=7.4.0→>=9.1.1)	D2 (CI gate)	test suite	no 9.1.x change matches suite shape; CI already runs 9.1.1 (unpinned pip install -e .[dev])
ruff	0.15.17 → 0.15.21 (floor →>=0.15.20)	D2 (CI gate)	lint/format gate	only enabled-set deltas are F-rule detection refinements; CI lint already runs unpinned latest
redis	8.0.0 → 8.0.1 (lock-only; extra floors stay >=5.0.0)	D1	lazy imports in celery/singleton.py, streams/checkpoint.py	all 8.0.1 fixes in unused subsystems; APIs used are stable across redis-py 5.x–8.x (downstream consumers on 6.x unaffected)

dashboard/backend

Package	Change	Tier	Touches	Notes
pydantic-settings	2.12.0 → 2.14.2 (lock-only)	D2	app/config.py (BaseSettings, env prefix + .env)	all in-range changes target CLI/cloud/secrets features we don't use; bump clears GHSA-4xgf-cpjx-pc3j (unused feature, but 2.12.0 was in affected range)

dashboard/frontend (25 npm)

Package	Change	Tier	Notes
react-hook-form	7.79.0 → 7.81.0	D2	deepEqual dirty-compare fix + useFieldArray error-placement fixes intersect profile-form.tsx; corrections, gates green
@radix-ui/react-slot	1.2.4 → 1.3.0	D2	React-19 ref-callback re-render fix in the asChild path used by button/form
@radix-ui/react-select	2.2.6 → 2.3.3	D2	presence-based exit animations; wrapper ui/select + 4 downstream
@radix-ui/react-avatar	1.1.11 → 1.2.2	D2	image-load render change (no flash on cached)
@tanstack/react-router	1.170.15 → 1.170.17	D2	useMatch/Match memoization perf changes on every-navigation render path; no API change
13 other @radix-ui/react-*	patch tail	D1	releases page documents no breaking changes; no unstable_* APIs used
lucide-react	1.18.0 → 1.24.0	D1	additive icon releases; zero overlap with our 48 imported icons
@types/node	25.9.3 → 26.1.1 (major)	D2	only Node-API consumer is vite.config.ts (path, __dirname); skipLibCheck on; tsc build verified green
prettier	3.8.3 → 3.9.5	D2	3.9.0 printer overhaul suspected D3 — disproved by execution: --check failing-file set byte-identical old vs new (37 pre-existing)
typescript-eslint	8.61.1 → 8.63.0	D2	every rule changed in range verified not enabled (non-type-aware config)
@types/react 19.2.17, eslint-plugin-react-refresh 0.5.3	patch	D2/D1	no relevant delta

Security

• OSV: zero advisories across all 33 bumped packages (pip + npm).
• npm supply-chain sweep (all 25): no new install/preinstall/postinstall scripts; radix maintainer change = WorkOS org-wide move to attested trusted publishing (provenance verified, predates this range); tanstack maintainer shrink = access cleanup, same attested publisher.
• Freshness flags (<3 days at review time): filelock 3.29.7 (2d), aws-durable-execution-sdk 1.7.0 (1d), ruff 0.15.21 (1d, already exercised by CI), lucide 1.24.0, prettier 3.9.5, @types/node 26.1.1. All provenance/pipeline-verified; nothing concrete supports holding them.

Executed evidence

Engine suite (Python 3.13, pip install -e .[dev]), new leg (croniter 6.2.3, filelock 3.29.7, click 8.4.2, redis 8.0.1, pytest 9.1.1):

tests/unit/         760 passed, 2 skipped, 7 warnings in 4.98s
tests/integration/  152 passed, 3 skipped in 22.46s

Old-leg CI-gate diffs (identical suite, one package pinned back at a time):

Gate	old	new	diff
pytest 9.0.3 vs 9.1.1 (full unit+integration)	760+152 passed	760+152 passed	identical
ruff 0.15.17 vs 0.15.21 check .	All checks passed	All checks passed	identical
ruff 0.15.17 vs 0.15.21 format --check .	237 files formatted	237 files formatted	identical
prettier 3.8.3 vs 3.9.5 --check . (frontend)	37 failing files	37 failing files	byte-identical file set (pre-existing debt)
frontend tsc -b && vite build / eslint . (old lock vs new lock)	build ✓, 7 errors/9 warnings	build ✓, 7 errors/9 warnings	identical (lint errors pre-existing on main)

D3 isolated old-vs-new regression legs (each leg pins back exactly one package, everything else held at new):

croniter 6.2.2 vs 6.2.3 — normal exprs and 59-element comma ranges: identical validate_cron_expression + get_next results from a fixed base. Zero-step exprs (*/0, 1-5/0, reversed 5-1/0): rejected on both legs; only divergence is exception type on reversed ranges (ValueError → CroniterBadCronError, which subclasses ValueError in both versions), fully absorbed by validate_cron_expression's except (ValueError, KeyError) → returns False, never crashes. Safe.

filelock 3.29.4 vs 3.29.7 — mutual exclusion (2 threads), release→reacquire, reacquire-over-stale-lockfile (post-upgrade simulation), and a real FileStorageBackend write+read roundtrip: identical on both legs. Single divergence = documented #577: .lock files persist after release. Cosmetic accumulation; no call site assumes lock-file absence. Operational note: .locks/ dirs grow unbounded (one file per distinct run/hook/schedule id) — possible future cleanup task. Safe.

click 8.4.1 vs 8.4.2 — pyworkflow --help and pyworkflow schedules --help: exit 0, byte-identical output on both legs. Safe.

Needs-judgment (human sign-off)

• aws-durable-execution-sdk-python 1.5.0 → 1.7.0: the suspend-vs-FAILED semantics change (chore(deps): bump lucide-react from 1.18.0 to 1.21.0 in /dashboard/frontend #492) sits inside @durable_execution, which pyworkflow/aws/handler.py wraps — and the repo has no tests exercising the real SDK (AWS path verified only against in-repo mocks), so this one cannot be execution-verified here. If the AWS runtime is in production use anywhere, verify a suspend/resume cycle on a real Lambda before relying on it; otherwise the floor raise to >=1.6.0 is the safest expression of intent.

Version bump

0.3.7 → 0.3.8 in pyproject.toml + pyworkflow/__init__.py (per RELEASING.md). This picks up #550 (STEP_SUSPENDED for inline step_hook suspensions) already on main — downstream urlslab-app is waiting on 0.3.8 to re-pin from the temporary fork rev.

Risk tier: Tier 3 (engine-critical paths touched by croniter/filelock; verified by execution as above).

[LivinTribunal]

D3 packages — what changed and what to test

Package	Bump	Why D3 (documented change × our usage)	Where we use it	How to verify manually
croniter	6.2.2 → 6.2.3	Upstream #232: zero-step cron ranges (*/0, 1-5/0, reversed 5-1/0) are now rejected at construction with CroniterBadCronError (old raised bare ValueError for reversed ranges). Both our call sites construct croniter() from user-supplied cron expressions, so the accept/reject surface changed.	pyworkflow/utils/schedule.py:113 (_next_cron_time → croniter(expr, base).get_next), schedule.py:348 (validate_cron_expression)	Create a schedule via CLI/dashboard with a normal expr (*/5 * * * *) → next-run time must be computed as before. Then try */0 * * * * and 5-1/0 * * * * → must be rejected with a clean validation error, not a crash/traceback.
filelock	3.29.4 → 3.29.7	Upstream #577: Unix .lock files are no longer deleted on release — they persist on disk. Every file-storage operation goes through with FileLock(...), so the on-disk behavior of the storage dir changed.	pyworkflow/storage/file.py — 25 call sites (base_path/.locks/<id>.lock)	Run any workflow on file storage → it must complete normally, and re-running against the same storage dir (now containing leftover .lock files) must also work. Expect .locks/ to accumulate files — that's the new normal, not a bug. Two concurrent runs on the same run-id must still serialize.
aws-durable-execution-sdk-python	1.5.0 → 1.7.0 (floor >=0.1.0 → >=1.6.0)	Upstream #492: a suspend is no longer surfaced as a FAILED outcome inside @durable_execution; #488/#504 change replay status/operation-IDs; 1.6.0 #476 changed the wait_for_callback context subtype. Our Lambda handler wraps whole workflows in @durable_execution and its except Exception path logs/raises whatever the SDK surfaces — the suspend-vs-FAILED change flows directly through code we own.	pyworkflow/aws/handler.py:139-145, pyworkflow/aws/context.py (.step(), .wait()), pyworkflow/context/aws.py (create_callback / callback.result())	This is the only D3 not verified by execution — the repo has zero real-SDK tests (mocks only). On a real Lambda: run a workflow that (a) suspends via .wait() / callback and resumes → the suspension must NOT be recorded as FAILED and the resume must replay correctly; (b) a genuinely failing step must still surface as FAILED. If the AWS runtime isn't in production use, merging on the floor raise alone is acceptable.

Verification already executed (isolated old-vs-new legs, one package pinned back at a time)

• croniter: normal + 59-element comma exprs → identical validate + get_next results from a fixed base on both legs; all three zero-step exprs rejected on both legs (old already rejected them — only the exception type diverged on reversed ranges, and CroniterBadCronError subclasses ValueError in both versions, so validate_cron_expression's except (ValueError, KeyError) returns False cleanly on both). Safe.
• filelock: mutual exclusion (2 threads), release→reacquire, reacquire-over-stale-lockfile (simulates first run after upgrading an existing storage dir), real FileStorageBackend write+read roundtrip → all identical on both legs. Single divergence = lock-file persistence, cosmetic. Safe.
• aws-durable-execution-sdk-python: not execution-verifiable locally (no real-SDK coverage) — see manual steps above. Needs judgment.

Full leg tables and the engine-suite/CI-gate diffs are in the PR body.

[LivinTribunal]

Verdict: safe to merge.

Verified: engine suite + CI gates identical old vs new; croniter/filelock/click checked in isolation; Celery suspend/resume E2E pass; urlslab-app full suite on this rev — zero regressions; OSV + npm supply chain clean.

@yasha-dev1 one thing to check: aws-durable-execution-sdk 1.5.0 → 1.7.0 changed suspend semantics inside @durable_execution and we have no real-SDK tests. If nobody runs the AWS/Lambda runtime in prod, merge as-is; otherwise verify one suspend/resume on Lambda first (or we drop that single bump).

Verification also surfaced ~8 pre-existing engine bugs (broken Celery retries, scheduler starvation, …) — not caused by this PR; issues with repros follow.

After merge: tag v0.3.8, urlslab-app re-pins to ^0.3.8.

[yasha-dev1]

no one's using that for now. we'll just merge

[LivinTribunal]

Pre-existing bugs from the verification, now filed with executed repros: #554 (P1 Celery retries broken on string retry_after), #552 (P1 scheduler tick starvation), #553 (trigger_schedule persist ordering), #555 (schedules CLI missing discovery), #556 (yaml-overrides-env broker footgun), #557 (resume-vs-sleep, schedule purge case bug, .locks growth). None are caused by this PR.

[LivinTribunal]

Stage-5 dashboard UI walkthrough done (backend+frontend booted from this branch, real run data): navigation/back-forward, runs table + filters, select, dropdown-menu, radio-group form submit (theme+font applied), Cmd+K dialog open/Esc-close with pointer-events intact, sidebar collapse — all pass, zero console errors. That was the last open verification leg; everything is now executed.