janpeter/Ops-dashboard
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

fix(ci): harnas-stub voor het nieuwe script, en een timeout die past bij de suite #133

Merged
janpeter merged 2 commits from fix/ci-harness-stub-and-timeout into main 2026-08-02 14:59:34 +02:00
Conversation 2 Commits 2 Files changed 2 +30
janpeter commented 2026-08-02 14:27:39 +02:00
Owner
Copy link

CI op ops-dashboard is rood sinds 2026-08-01 (laatst groen 07-31). Twee onafhankelijke oorzaken; de tweede stond er al vóór mijn werk van vandaag.

1. Mijn regressie — deterministisch, 2 tests

ENOENT: no such file or directory, copyfile
  '.../root/repository/deploy/ops-agent/scripts/scrum4us-deploy-trigger.sh'

setup.sh installeert sinds de deploy-trigger-PR een derde script, maar de hermetische harnas bouwt de nep-repo uit een vaste lijst en schreef alleen stubs voor repo-contains-sha.sh en update-operator-mcp.sh. Gevolg: setup.sh viel om en de twee tests die runSetupBoundary() gebruiken faalden — met een melding die naar /tmp wijst in plaats van naar die lijst.

Toerekening gemeten, niet aangenomen: de ENOENT verschijnt precies op de runs waarvan de branch die setup.sh-regel draagt (#87, #89, #90, #92) en is nul op #91, dat van een main zonder die commit is afgetakt. Alleen de tests op regel 900 en 935 roepen runSetupBoundary() aan, dus de overige failures cascaderen er niet uit.

2. Niet van mij — een limiet die niet past bij de suite

Gemeten in CI-run #92:

bestand tests duur gemiddeld
control-room-foundation.test.ts 80 232.858 ms 2,9 s/test
control-room-runner.test.ts 87 43.050 ms 0,5 s/test
alle overige 60+ — 7-33 ms per bestand —

Er stond geen testTimeout in vitest.config.ts, dus vitest' default van 5000 ms gold. Gemiddeld 2,9 s tegen 5 s is geen factor 2 marge, dus bij belasting kiepert er een wisselend handjevol om: 8 timeouts in run #91, 35 in run #90, over zeven verschillende testbestanden. Deze tests starten per stuk een subprocess dat echt filesystem-werk doet — de limiet paste niet bij wat ze doen.

testTimeout en hookTimeout op 30 s. Bewust globaal: dezelfde flakiness raakte zeven bestanden, en de snelle tests (tientallen ms) komen hier nooit in de buurt. De prijs is dat een écht hangende test er 30 s over doet om te falen in plaats van 5 s.

Wat hier bewust NIET in zit

Lokaal faalt control-room-foundation.test.ts op iets heel anders: CONTROL_ROOM_FOUNDATION_FAILED: reviewed_unit_untrusted:ops-agent.service — een directe assertie, geen timeout, 65 van de 80 tests. Dat is een derde, losstaand probleem in de lokale omgeving en niet wat CI rood maakte. Ik heb het niet meegenomen om deze PR bij zijn onderwerp te houden, maar het is het melden waard: het betekent dat deze suite lokaal geen bruikbaar oracle is.

CI op ops-dashboard is rood sinds **2026-08-01** (laatst groen 07-31). Twee onafhankelijke oorzaken; de tweede stond er al vóór mijn werk van vandaag. ## 1. Mijn regressie — deterministisch, 2 tests ``` ENOENT: no such file or directory, copyfile '.../root/repository/deploy/ops-agent/scripts/scrum4us-deploy-trigger.sh' ``` `setup.sh` installeert sinds de deploy-trigger-PR een derde script, maar de hermetische harnas bouwt de nep-repo uit een **vaste lijst** en schreef alleen stubs voor `repo-contains-sha.sh` en `update-operator-mcp.sh`. Gevolg: `setup.sh` viel om en de twee tests die `runSetupBoundary()` gebruiken faalden — met een melding die naar `/tmp` wijst in plaats van naar die lijst. **Toerekening gemeten, niet aangenomen:** de ENOENT verschijnt precies op de runs waarvan de branch die `setup.sh`-regel draagt (#87, #89, #90, #92) en is **nul** op #91, dat van een main zonder die commit is afgetakt. Alleen de tests op regel 900 en 935 roepen `runSetupBoundary()` aan, dus de overige failures cascaderen er niet uit. ## 2. Niet van mij — een limiet die niet past bij de suite Gemeten in CI-run #92: | bestand | tests | duur | gemiddeld | |---|---|---|---| | `control-room-foundation.test.ts` | 80 | 232.858 ms | **2,9 s/test** | | `control-room-runner.test.ts` | 87 | 43.050 ms | 0,5 s/test | | alle overige 60+ | — | 7-33 ms per bestand | — | Er stond geen `testTimeout` in `vitest.config.ts`, dus vitest' default van **5000 ms** gold. Gemiddeld 2,9 s tegen 5 s is geen factor 2 marge, dus bij belasting kiepert er een wisselend handjevol om: **8 timeouts in run #91, 35 in run #90**, over zeven verschillende testbestanden. Deze tests starten per stuk een subprocess dat echt filesystem-werk doet — de limiet paste niet bij wat ze doen. `testTimeout` en `hookTimeout` op 30 s. **Bewust globaal**: dezelfde flakiness raakte zeven bestanden, en de snelle tests (tientallen ms) komen hier nooit in de buurt. De prijs is dat een écht hangende test er 30 s over doet om te falen in plaats van 5 s. ## Wat hier bewust NIET in zit Lokaal faalt `control-room-foundation.test.ts` op iets heel anders: `CONTROL_ROOM_FOUNDATION_FAILED: reviewed_unit_untrusted:ops-agent.service` — een directe assertie, geen timeout, 65 van de 80 tests. Dat is een **derde**, losstaand probleem in de lokale omgeving en niet wat CI rood maakte. Ik heb het niet meegenomen om deze PR bij zijn onderwerp te houden, maar het is het melden waard: het betekent dat deze suite lokaal geen bruikbaar oracle is.
fix(ci): harnas-stub voor het nieuwe script, en een timeout die past bij de suite
Some checks failed
CI / Root app checks (pull_request) Failing after 4m35s
Details
CI / Ops-agent checks (pull_request) Successful in 15s
Details
CI / Deploy artifact checks (pull_request) Successful in 12s
Details
CI / Docker image build (pull_request) Successful in 1m27s
Details
a0d7dc2ca0 
Twee losse oorzaken achter de rode CI op ops-dashboard. CI ging stuk op 2026-08-01
(laatst groen 07-31), dus de tweede stond er al voor mijn werk van vandaag.

1. MIJN REGRESSIE, deterministisch, 2 tests.
   setup.sh installeert sinds de deploy-trigger-PR een derde script, maar de
   hermetische harnas bouwt de nep-repo uit een vaste lijst en schreef alleen stubs
   voor repo-contains-sha.sh en update-operator-mcp.sh. Gevolg: setup.sh viel om op
   ENOENT bij copyfile, en de twee tests die runSetupBoundary() gebruiken faalden —
   met een melding die naar /tmp wees in plaats van naar die lijst. Stub toegevoegd,
   met een comment dat de lijst moet meebewegen.

   Toerekening is gemeten, niet aangenomen: de ENOENT verschijnt precies op de runs
   waarvan de branch die setup.sh-regel draagt (#87 #89 #90 #92) en is nul op #91,
   dat van een main zonder die commit is afgetakt.

2. NIET VAN MIJ: de control-room-suites liepen tegen vitest' default van 5000ms.
   Gemeten in CI-run #92:
     control-room-foundation.test.ts  80 tests in 232858ms -> ~2,9s per test
     control-room-runner.test.ts      87 tests in  43050ms -> ~0,5s per test
     alle overige 60+ bestanden       7-33ms per bestand
   Gemiddeld 2,9s tegen een limiet van 5s is geen factor 2 marge, dus bij belasting
   kiepert er een wisselend handjevol om: 8 timeouts in run #91, 35 in run #90, over
   zeven verschillende testbestanden. Deze tests starten per stuk een subprocess dat
   echt filesystem-werk doet; de limiet paste simpelweg niet bij wat ze doen.
   testTimeout en hookTimeout op 30s. Globaal, omdat dezelfde flakiness zeven
   bestanden raakte en de snelle tests (tientallen ms) hier nooit in de buurt komen.
   De prijs: een echt hangende test doet er 30s over om te falen in plaats van 5s.

Niet meegefixt, bewust: lokaal faalt control-room-foundation.test.ts op iets anders
(CONTROL_ROOM_FOUNDATION_FAILED: reviewed_unit_untrusted:ops-agent.service, een
directe assertie zonder timeout). Dat is een derde, losstaand probleem in de lokale
omgeving en niet wat CI rood maakte.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
s4m-codex-reviewer approved these changes 2026-08-02 14:31:10 +02:00
Dismissed
s4m-codex-reviewer left a comment
Copy link

Verdict: APPROVED

geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

  • Geen findings. De toegevoegde harnasstub in test/control-room-foundation-harness.ts:445 sluit aan op de bestaande lijst scripts die setup.sh tijdens de boundary-tests kopieert. De verhoogde testTimeout en hookTimeout in vitest.config.ts:20 zijn gemotiveerd voor subprocess- en filesystem-intensieve control-room suites en schakelen geen tests of assertions uit.

Product-standaarden

Productdocs bevatten geen specifieke aanvullende norm voor deze CI/test-harnaswijziging. De diff blijft klein, hergebruikt bestaande configuratiepunten en wijkt niet zichtbaar af van de agent-guide-principes voor minimale, gerichte wijzigingen.

# Verdict: APPROVED geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings - Geen findings. De toegevoegde harnasstub in `test/control-room-foundation-harness.ts:445` sluit aan op de bestaande lijst scripts die `setup.sh` tijdens de boundary-tests kopieert. De verhoogde `testTimeout` en `hookTimeout` in `vitest.config.ts:20` zijn gemotiveerd voor subprocess- en filesystem-intensieve control-room suites en schakelen geen tests of assertions uit. ## Product-standaarden Productdocs bevatten geen specifieke aanvullende norm voor deze CI/test-harnaswijziging. De diff blijft klein, hergebruikt bestaande configuratiepunten en wijkt niet zichtbaar af van de agent-guide-principes voor minimale, gerichte wijzigingen.
fix(ci): unhandled pipe-errors in de foundation-harnas afvangen
All checks were successful
CI / Root app checks (pull_request) Successful in 5m58s
Details
CI / Ops-agent checks (pull_request) Successful in 14s
Details
CI / Deploy artifact checks (pull_request) Successful in 12s
Details
CI / Docker image build (pull_request) Successful in 1m34s
Details
af323e8f70 
Met de vorige twee fixes erin slaagden in CI-run #93 alle 1096 tests (68/68
bestanden), maar de job bleef falen: vitest telde 47 unhandled errors en gaf exit 1.

  Test Files  68 passed (68)
       Tests  1096 passed (1096)
      Errors  47 errors
  Serialized Error: { errno: -104, code: 'ECONNRESET', syscall: 'read' }
   ❯ Pipe.onStreamRead node:internal/stream_base_commons:216:20

runHarnessProcess spawnt met stdio ['ignore','pipe','pipe','pipe'] en ving alleen
child.on('error') af. De drie streams zelf hadden geen listener. Veel scenario's laten
het script bewust vroegtijdig afbreken, dus een pipe die daarna reset is hier normaal
gedrag — maar zonder listener wordt het een unhandled error die de exit-code bepaalt
terwijl elke test groen is.

Handlers toegevoegd op stdout, stderr en de fd-3-descriptor. Bewust stil: de uitkomst
komt uit 'close' plus de exit-code, dus een gereset pipe na afloop zegt niets over de
test. Met comment, anders leest het als een weggemoffelde fout.

Buiten scope maar het melden waard: test/control-room-process.test.ts spawnt ook twee
processen zonder enige error-handler. Diezelfde klasse, maar de 47 errors kwamen
aantoonbaar uit control-room-foundation.test.ts, dus daar niet aan gezeten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
s4m-codex-reviewer approved these changes 2026-08-02 14:41:02 +02:00
s4m-codex-reviewer left a comment
Copy link

Verdict: APPROVED

Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

Geen blokkerende of error-severity findings.

  • INFO — test/control-room-foundation-harness.ts:443 — De extra scrum4us-deploy-trigger.sh stub houdt het testharnas in lijn met de scripts die setup.sh installeert; dit voorkomt een misleidende ENOENT in tijdelijke testdirectories.
  • INFO — test/control-room-foundation-harness.ts:569 — Stream error listeners voorkomen dat late pipe-reset errors na child-procesafsluiting Vitest laten falen terwijl de testuitkomst uit close/exit-code komt. Dit is beperkt tot het testharnas.
  • INFO — vitest.config.ts:20 — De hogere globale testTimeout/hookTimeout is onderbouwd met CI-metingen voor subprocess-heavy control-room suites. De trade-off is acceptabel voor deze testset en wijzigt geen productiegedrag.
# Verdict: APPROVED Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings Geen blokkerende of error-severity findings. - INFO — `test/control-room-foundation-harness.ts:443` — De extra `scrum4us-deploy-trigger.sh` stub houdt het testharnas in lijn met de scripts die `setup.sh` installeert; dit voorkomt een misleidende ENOENT in tijdelijke testdirectories. - INFO — `test/control-room-foundation-harness.ts:569` — Stream `error` listeners voorkomen dat late pipe-reset errors na child-procesafsluiting Vitest laten falen terwijl de testuitkomst uit `close`/exit-code komt. Dit is beperkt tot het testharnas. - INFO — `vitest.config.ts:20` — De hogere globale `testTimeout`/`hookTimeout` is onderbouwd met CI-metingen voor subprocess-heavy control-room suites. De trade-off is acceptabel voor deze testset en wijzigt geen productiegedrag.
Sign in to join this conversation.
Reviewers
No reviewers
s4m-codex-reviewer
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
janpeter/Ops-dashboard!133
No description provided.