500 server error bij stukdeel die niet bestaat

[melsk-r]

Originally created by fsamwel (kadaster/BRK-bevragen#955):

bijvoorbeeld /stukdelen/123456789012 geeft:
{
"type": "https://docs.microsoft.com/en-us/dotnet/api/system.net.httpstatuscode?#System_Net_HttpStatusCode_InternalServerError",
"title": "Interne server fout.",
"status": 500,
"detail": "Internal Server Error",
"instance": "/stukdelen/123456789012",
"code": "serverError"
}

ik had dan een 404 fout verwacht

[melsk-r]

This comment originally might have been created by someone else.

Gebruikers zullen de stukdeel identificaties uit een eerdere response halen, er is daarmee geen aanleiding (& prioriteit) vanuit gebruikers om dit nu te moeten oplossen.

Het liefste sluit ik deze bug voor nu, en openen we een nieuwe als gebruikers hier in de praktijk tegenaan lopen.

[melsk-r]

This comment originally might have been created by someone else.

Bedoel je dat men de 'stukdeelidentificaties' eerder heeft verkregen via een response van een GET '/stukken/{stukIdentificatie}'? Dat er daardoor vanuit gegaan mag worden dat als men op basis daarvan een GET '/stukdelen/{stukdeelIdentificatie}' ophaalt deze ook altijd zal bestaan en er dus nooit een 500 voor zal komen wat voor jou genoeg reden is om geen 404 voor deze situaties te implementeren. Correct?

[melsk-r]

This comment originally might have been created by someone else.

Dat is helemaal correct. deze stukdeelidentificaties zijn niet op een andere manier te verkrijgen.

[melsk-r]

This comment originally might have been created by someone else.

Wij (@JohanBoer en ik) hebben het er nog even samen over gehad en we stellen het sluiten van dit issue toch nog even ter discussie. Het gaat hier nl. om een doodgewone bug en gebruikers die hier tegenaan lopen hebben geen flauw idee wat er gebeurt. Het klopt dat hier normaliter (de happy flow) nooit iemand tegen aan zal lopen, maar als een developer gewoon een fout maakt en het verkeerde id in de stukdeelidentificatie stopt dan wordt het moeilijk debuggen.

Wij begrijpen de insteek om de prioriteit hier niet al te hoog te leggen, maar een bekende (en terechte) bug sluiten en opnieuw opvoeren als de gebruikers er tegenaan lopen vinden wij een brug te ver.

[melsk-r]

This comment originally might have been created by someone else.

Deze komt alleen voor op Externe Testomgeving, dus is geen bug. Externe Testomgeving dient nog gelijk getrokken te worden. Marcel koppelt terug.