Jadpo is experimental and not ready for production. These docs follow the compiler's main branch as of 5 Nov 2026. What's built · Install 0.3.0
jadpo
ReferenceErrors

ErrorsExternal services · rule

test.recording_undecodable

On this page

A saved answer from an outside service doesn't fit the types your integration reads that answer as.

Area 11, External services; not declinable; the next step is usually the agent's.

Why Jadpo refuses it

A recording is a real answer from the provider, kept in the package as recordings/<resource>.<operation>.json. jadpo test reads each one through the operation's output type and the package's own decoders, just as a real call's answer is read. One that doesn't decode shows that the types don't match what the provider sends, so a real answer like it would make the call fail.

What it looks like

The app's own integration for Acme Couriers reads a booking's status as its Status enum, which has the values booked and on_hold.

shared/providers/acme_couriers/v1/types/booking.jadpo:

example
/// A booked collection.public type Booking = Object {    id: Text    status: Status}

The recording of creating a booking holds a status of lost.

shared/providers/acme_couriers/v1/recordings/bookings.create.json:

example
{  "data": {    "id": "{Text}",    "status": "lost"  }}
text
FAIL  bookings.create's recording decodes --> shared/providers/acme_couriers/v1/recordings/bookings.create.json:1  decode: `bookings.create`'s recording doesn't decode: `variant` on `status`  reason: Every decoder decodes every recorded answer: the operation's output type, or a decoder of its own, refuses what the provider sent here, so a real answer like it would fault the call.  next: Correct the type or its decoder against the recording and the provider's documentation (agent)  rule: test.recording_undecodable  rerun: jadpo test shared/providers/acme_couriers/v1/recordings/bookings.create.json:1 --seed 1test failed: 1 failed, 1 recording test

(agent) at the end of the next: line means your coding agent can make the fix itself.

How to fix it

The question is which is wrong: the type, or the recording. The provider's documentation says which values it sends.

If the provider does send that value, add it to the type. In shared/providers/acme_couriers/v1/types/status.jadpo:

example
    lost

The recording decodes, and so does a real answer with a status of lost. A match on Status in your code now has to handle lost too.

If the recording is wrong, such as one edited by hand, correct it to what the provider sends. In shared/providers/acme_couriers/v1/recordings/bookings.create.json:

json
    "status": "on_hold"

The recording decodes again. Recording the operation again from the provider's sandbox, with jadpo package record, replaces the file with a real answer.

Markdown for agents: /docs/errors/test.recording_undecodable.md.Built from Jadpo main at aee2e8f.