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) |
||
|---|---|---|
| .. | ||
| widgets | ||
| admin.js | ||
| app.js | ||
| board.js | ||
| cms.js | ||
| core.js | ||
| data.js | ||
| explorer.js | ||
| image-catalog.js | ||
| parent.js | ||
| permissions.js | ||
| picker.js | ||
| pupil.js | ||
| settings.js | ||