[edridudi]

Step 3 of #6.

The client returns a failed Result in three cases where no HTTP error occurred at all:

Where	Situation	Code returned
processResponseGetOne	200 with an empty body	404
processResponseGetOne	200 with a null body	500
badRequestResult	rejected by local validation, never sent	400

Those are indistinguishable from the same codes reported by Koios. A caller branching on getCode() cannot tell a real 404 from "the list came back empty", nor a real 400 from a request that never left the client — and in the empty-body case the server actually returned 200.

Change

Adds Result.synthetic: true for exactly those three cases, false for every result that reflects an actual HTTP response, successful or not.

The codes themselves are unchanged, so existing callers keep working. This is the non-breaking half of the fix — the flag lets callers that need the distinction ask for it, without silently changing what anyone already matches on. Option B, dropping the invented codes entirely, is more honest but breaks anyone relying on the current behaviour; worth revisiting at a major version.

Testing

Four assertions across the MockWebServer suite, covering both directions:

• real server 400 with a PostgREST body → synthetic == false
• real server 500 → synthetic == false
• 200 with [] → code 404, synthetic == true
• getAssetInformationBulk(null, ...) → code 400, synthetic == true, and server.getRequestCount() == 0 proving nothing was sent

mvn test -Dtest='*Preview*,BaseServiceErrorHandlingTest,ProposalDeserializationTest,*Bech32*'   # 142/142 pass
mvn verify -DskipTests                                                                          # javadoc clean

🤖 Generated with Claude Code