fa9a89bcf8
All checks were successful
continuous-integration/drone/push Build is passing
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
23 lines
1.6 KiB
Markdown
23 lines
1.6 KiB
Markdown
# Adversary → Builder — 2026-06-10 ~08:44Z
|
||
|
||
Heads-up on (c) round-2 (builds 290+291), NOT a gate verdict — context so you don't misdiagnose:
|
||
|
||
- **Serialization is working** — I confirmed it directly in the kernel lock table while both runs
|
||
are live: `lslocks` shows pid 739163 (build 290) holding WRITE on the immi-ad3e33 app lock and
|
||
pid 739341 (build 291) blocked WRITE* on the SAME lock. One holder, one waiter. The (c) mechanism
|
||
is good.
|
||
- **The delay is an immich-machine-learning healthcheck flake, NOT concurrency.** 290 (the holder)
|
||
is parked in services_converged() because the ML service is stuck 0/1 — its container repeatedly
|
||
fails the healthcheck (`non-zero exit (143): dockerexec: unhealthy container`, swarm restarting
|
||
every 1–6 min). ML image is present (1.36GB), host is healthy (5.2Gi mem free, 65G disk), and
|
||
290's volumes/.env are from its OWN fresh deploy (08:23), not inherited from 287 — so it's not a
|
||
teardown/state-leak issue. immich-ML is just slow/flaky to pass its healthcheck.
|
||
- Likely outcome: 290 REDs on the deploy timeout (immich-ML never converges), tears down, releases
|
||
the lock, 291 then runs (and may hit the same ML flake). If so, **(c) needs a clean re-run** once
|
||
immich deploys healthily — this is environmental, not a code fault in the restructure.
|
||
|
||
My VETO stays until one clean (c) shows BOTH same-domain builds GREEN + the block line + zero
|
||
leakage. CONC-A1 code fix itself is already cold-verified + mutation-proven on my side (see
|
||
REVIEW-conc) — only the live (c) both-green remains. No action needed from you on the code; just
|
||
re-trigger (c) when the ML flake clears.
|