45f66044f2
All checks were successful
dev - build & deploy naar test / build-and-deploy (push) Successful in 38s
De echte, uiteindelijke oorzaak achter elke "serverfout" die niet door een route-eigen foutafhandeling kwam (klas verwijderen, en zeer waarschijnlijk ook de oorspronkelijke gebruiker-verwijderen-bug): de client stuurde bij élk verzoek altijd "Content-Type: application/json" mee, ook bij een DELETE zonder body. Fastify's standaard JSON-parser weigert zo'n leeg lichaam met "Body cannot be empty when content-type is set to 'application/json'" - vóórdat er ook maar één hook of route-handler heeft kunnen draaien, dus nog vóór req.user gezet wordt en vóór enige try/catch in een route. Dat verklaart waarom eerdere per-route foutafhandeling dit nooit kon vangen: de fout zat vóór elke route. - public/js/core.js: api() stuurt Content-Type alleen nog mee als er werkelijk een JSON-body is - src/body-parser.js (nieuw): serverside vangnet dat een leeg lichaam bij Content-Type: application/json gewoon toestaat i.p.v. te weigeren - ongeacht wat een client meestuurt - test/body-parser.test.js: reproduceert de exacte foutmelding tegen een echte Fastify-requestcyclus (de gemockte-pool-tests konden dit principieel nooit vangen, vandaar dat dit alle eerdere testrondes overleefde) |
||
|---|---|---|
| .. | ||
| api-security.test.js | ||
| auth.test.js | ||
| body-parser.test.js | ||
| cms.test.js | ||
| frontend.test.js | ||
| images.test.js | ||
| language-library.test.js | ||
| parent-portal.test.js | ||
| save-system.test.js | ||
| schools.test.js | ||
| security-config.test.js | ||
| shared-library.test.js | ||
| widgets.test.js | ||