Skip to content

fix: correct three contract failures in the collections - #28

Merged
roncodes merged 1 commit into
mainfrom
fix/order-proof-and-destination
Aug 11, 2026
Merged

roncodes merged 1 commit into
mainfrom
fix/order-proof-and-destination

Conversation

@roncodes

Copy link
Copy Markdown
Member

Three collection-side failures found by the contract run.

Set Order Destination sent the wrong id

It 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 with Place resource is not a valid destination. (422).

Create an Order already 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 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 (fleetbase/fleetbase#595).

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.

This only surfaced now: once #27 made Upload File send a real PNG, the download returned image/png and 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-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, not excused: non-empty body and a declared content type.

Not fixed here, and why

Capture QR Code for Order also fails, and it is not coverable from public API data: captureQrScan requires $code === $subject->uuid, and the public API deliberately never exposes uuids (qr_code on the Entity and Order resources is $this->when($isInternal, ...)). Same reason Decode Tracking Number QR cannot pass. Both are being tracked as documented exclusions rather than papered over.

🤖 Generated with Claude Code

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>
@roncodes
roncodes merged commit 632dcfe into main Aug 11, 2026
1 check passed
@roncodes
roncodes deleted the fix/order-proof-and-destination branch August 11, 2026 08:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant