fix: correct three contract failures in the collections - #28
Merged
Merged
Conversation
Set Order Destination sent {{place_id}}.
The destination must be one of the ORDER's own stops — resolveServiceStopFromKey
matches against the payload's places and waypoints — so a standalone place from
the Places folder is rejected with "Place resource is not a valid destination."
(422). Create an Order already captures {{waypoint_id}} from the order it made,
which is exactly what this endpoint wants. The description now says so.
Capture Signature for Order sent an empty signature.
The body shipped "signature": "" literally, so the endpoint answered "No
signature data to capture." before doing anything. It now takes
{{proof_signature_base64}}, injected by the contract action.
Download File was asserted to return JSON.
The collection-level script asserts a JSON body on every response, but this
endpoint streams the stored file — Storage::download() sends
Content-Disposition: attachment and the file's own content type. Once Upload
File began sending a real PNG, the assertion failed with "expected 'image/png'
to include 'json'": the only failure left in a 24/24 collection.
The script now branches on Content-Disposition rather than on the request name,
so any future download endpoint is covered without another exception — and a
regular endpoint that unexpectedly started returning a file would still be
caught. Downloads are still asserted: non-empty body, declared content type.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three collection-side failures found by the contract run.
Set Order Destinationsent the wrong idIt used
{{place_id}}— a standalone place from the Places folder. The destination must be one of the order's own stops:resolveServiceStopFromKey()matches against the payload's places and waypoints, so anything else is rejected withPlace resource is not a valid destination.(422).Create an Orderalready captures{{waypoint_id}}from the order it just made, which is exactly what this endpoint wants. The description now states the constraint.Capture Signature for Ordersent an empty signatureThe body shipped
"signature": ""literally, so the endpoint answeredNo signature data to capture.before doing anything. It now takes{{proof_signature_base64}}, injected by the contract action (fleetbase/fleetbase#595).Download Filewas asserted to return JSONThe collection-level script asserts a JSON body on every response, but this endpoint streams the stored file —
Storage::download()sendsContent-Disposition: attachmentand the file's own content type.This only surfaced now: once #27 made Upload File send a real PNG, the download returned
image/pngand the assertion failed with "expected 'image/png' to include 'json'" — the only remaining failure in a collection that is otherwise 24/24.The script now branches on
Content-Dispositionrather than on the request name, so any future download endpoint is covered without another exception, and a regular endpoint that unexpectedly started returning a file would still be caught. Downloads are still asserted, not excused: non-empty body and a declared content type.Not fixed here, and why
Capture QR Code for Orderalso fails, and it is not coverable from public API data:captureQrScanrequires$code === $subject->uuid, and the public API deliberately never exposes uuids (qr_codeon the Entity and Order resources is$this->when($isInternal, ...)). Same reasonDecode Tracking Number QRcannot pass. Both are being tracked as documented exclusions rather than papered over.🤖 Generated with Claude Code