Skip to content

fix(fleetops): repair three broken variable chains - #31

Merged
roncodes merged 1 commit into
mainfrom
fix/fleetops-captures-and-contact-type
Aug 11, 2026
Merged

roncodes merged 1 commit into
mainfrom
fix/fleetops-captures-and-contact-type

Conversation

@roncodes

Copy link
Copy Markdown
Member

Three more failures from the contract run, all in the collection rather than the API.

Retrieve an Order Config set its own id

It captured {{order_config_id}} in its own afterResponse — which cannot work, because the value has to exist before the request is sent. The URL went out as /order-configs/%7B%7Border_config_id%7D%7D and answered "Order config not found."

Query Order Configs runs first and is the natural source, so it captures the id now.

Render Label addressed a variable nothing set

{{label_subject_id}} had no source anywhere, so the request rendered the literal placeholder and answered "Unable to render label." The request already pins type=order, so it now renders {{order_id}} — a label for the order the collection just created.

Update a Contact documented an operation the API forbids

Create a Contact makes a contact with "type": "customer", and the update sent "type": "technician". The API refuses that deliberately — "Customer contact type cannot be changed." — because the contact is linked to a customer record.

type is dropped from the update rather than changing what Create a Contact makes: updating name, title, email and phone is the real use case, and a customer contact whose type is immutable is the behaviour worth documenting.

Related

Delete a Zone's 404 turned out not to be a collection or API problem at all — the contract runner defers deletes and was removing the parent service area first. Fixed in fleetbase/fleetbase#598.

🤖 Generated with Claude Code

@roncodes
roncodes force-pushed the fix/fleetops-captures-and-contact-type branch from 9075742 to 6dd1379 Compare August 11, 2026 10:57
Retrieve an Order Config set {{order_config_id}} in its OWN afterResponse.
  That cannot work — the value has to exist before the request is sent, so the
  URL went out as /order-configs/%7B%7Border_config_id%7D%7D and answered "Order
  config not found." Query Order Configs runs first and is the natural source, so
  it captures the id now.

Render Label addressed {{label_subject_id}}, which nothing set.
  It answered "Unable to render label." for the literal placeholder. The request
  already pins type=order, so it renders {{order_id}} — a label for the order the
  collection just created.

Update a Contact tried to change a customer contact's type.
  Create a Contact makes one with "type": "customer", and the update sent
  "type": "technician". The API refuses that deliberately —
  "Customer contact type cannot be changed." — because the contact is linked to a
  customer record. The example was documenting an operation the API does not allow.

  `type` is dropped rather than the create being changed: updating a contact's
  name, title, email and phone is the real use case, and a customer contact whose
  type is immutable is the behaviour worth showing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@roncodes
roncodes force-pushed the fix/fleetops-captures-and-contact-type branch from 6dd1379 to af0cb02 Compare August 11, 2026 10:59
@roncodes
roncodes merged commit c166b63 into main Aug 11, 2026
1 check passed
@roncodes
roncodes deleted the fix/fleetops-captures-and-contact-type branch August 11, 2026 11:08
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