Skip to main content

​
First, separate the two kinds of failure

Every problem you will hit falls on one side of a line:
  • The target failed. Your partner’s implementation broke a rule. This is always reported inside a finished run: a failed check or verdict with the recorded exchange and the clause attached. It never arrives as an HTTP error from our API.
  • We did not get an answer. Your request to our API was rejected, rate limited, or our runner was unavailable. This arrives as an HTTP status and says nothing about your partner.
A CI script that conflates these will tell your partner they are broken when the truth is that your script never got an answer. Keep the exit codes apart, as in the scripts in Run a suite and Run a charging journey.

​
Status codes

A 202 is not an error and not an outcome: the work was accepted and is still going. Poll or wait for the result.

​
Registration

Everything returns 401 after a successful registration. The partner is almost certainly still presenting the registration token (Token A). It was valid until the handshake completed, and then it died. After registration each side authenticates with the token the other side generated during the exchange. Registration succeeds, then the partner cannot push anything to you. They probably never fetched your endpoints. A credentials POST obliges the server to go and read the client’s endpoints for that version. Skipping it registers fine and then fails days later, disguised as “your callbacks are broken”. The first authenticated request fails and the error makes no sense. Check the version on the connection. OCPI 2.1.1 sends the credentials token raw; from 2.2 onwards it is Base64 encoded. A version mismatch fails at the auth layer and looks nothing like a version problem. A second registration attempt succeeds. That is your partner’s bug, not yours. The spec requires 405 Method Not Allowed for a POST from an already-registered client. Registration is not idempotent, and a server that quietly re-registers is masking a state-machine bug somewhere.

​
Conformance runs

The run refuses a module. The selected OCPI version does not advertise it. That is not a gap in your setup: a module with no proven suite on that version is not advertised, because a run that reports failures you cannot act on is worse than one that says the module is not covered. See Run a suite. A scenario fails on a late step but the endpoint looks healthy. Scenarios chain their own output: each step feeds the next. A red step 6 with a healthy endpoint usually means something upstream returned nothing usable. Read the exchange on the first red step, not the last. My build fails and every failure is a warning. Then your build is gated wrongly. Gate on failed, not on warnings. A warning means a recommendation was declined, and declining a recommendation breaks no rule. See Read your report.

​
Charging journeys

The run says recovering. Do I need to do anything? No. Our runner is resuming from its checkpoint after a restart on our side. No request is repeated, and the run continues on its own. The run says recovery_required. The delivery of one mutating action is uncertain and the tester will not resend it automatically, because a replayed mutation could duplicate a session or a CDR on your partner’s side. The run is paused for your decision. Read the run, look at the server-offered recoveryOptions, and apply one with the current recoveryVersion. A stale version answers 409: re-read and decide again. See Run a charging journey. runIntegrity is degraded or invalid. Did my partner fail? No. Run integrity describes how complete our evidence is, never your partner’s conduct. Target failures appear as failed verdicts with the exchange attached. A degraded run means part of the story is unobservable, usually because a recovery decision chose to continue without replay. The start returned 503. Our journey runner is unavailable. Nothing was admitted and nothing reached your partner. Start again later; with the same Idempotency-Key, the retry either returns the original run or admits it fresh, never both.

​
Verdicts

The report says “Compliant” but there are warnings. Am I compliant? Yes. Nothing failed. A partner who ignores a SHOULD has broken nothing, and we will not send you to fix code that already works. A check passed. How do I know it can even fail? Because we broke our own server on purpose and made sure it did. Every OCPI 2.2.1 conformance check has been proven capable of failing, and that is enforced in our build. The reasoning, and the limits of the claim, are in Read your report.

​
Still stuck

Every check carries the request that was sent and the response that came back. Open the failing check and read the exchange before assuming the verdict is wrong. If the exchange shows the tester doing something the specification does not permit, that is our bug, and we want to know: ahoy@synergyboat.com.