The truck that drove 208 km and reported as stationary

A truck drove 208 kilometres on a Tuesday. Our trip list showed it stationary all day. No error, no empty state, no failed request — a successful response, parsed without complaint, containing nothing.

Two shapes, one endpoint

Trips come from events/load, and its answer depends on how the account is configured. With one trip detector, the response carries a flat list under selector.trips. With several, it carries a list of interval blocks instead, and the trips live under selector[i].d inside each block.

Both are documented behaviour. Neither is an error. A client written against a test account with one detector reads selector.trips, finds nothing on an account with two, and reports an empty day.

// one detector
{ selector: { trips: [ ... ] } }

// several detectors
{ selector: [ { d: [ ... ] }, { d: [ ... ] } ] }

The fix is not clever: read both, in one function, and never anywhere else. What made this expensive was that the failure looked like data. A fleet where some units drive and some do not is exactly what a fleet looks like.

The detalization bitmask

The second trap in the same call. detalization decides which parts of a trip record come back, and the parts you did not ask for are not missing — they are empty. The bits:

• 1 — the endpoints
• 4 — the parameters
• 8 — the encoded track
• 16 — the raw messages
• 32 — the formatted strings

Ask for 192 and you get trip objects with no keys at all: a list of the right length, full of nothing. Ask for 239 — everything except the raw messages — and you get a usable trip. The messages are left out on purpose: a fleet week of them is megabytes, and a route's own positions are a cheaper second call at 17 for the one trip somebody actually wants to see.

What this has to do with an assistant

These are the traps that make "just call the API from the model" a bad plan. A language model handed the raw endpoint will read one shape, get an empty list, and tell the user their truck did not move — fluently, and with no indication that anything went wrong.

So the shape handling lives in a tool, the tool is the only thing that touches events/load, and the model gets trips. The interesting part of building on Wialon is not the model. It is knowing which of the two answers you are looking at.