Spec drift: opinion — REST response envelope uses errno/errmsg in code but docs specify code/msg

[realfishsam]

Exchange

opinion

Drift Type

changed_response

Severity

HIGH — If the live API ever returns the documented code/msg envelope (not errno/errmsg), the success-check guard in fetcher.ts will always pass regardless of error status, silently swallowing API errors.

Their Docs

Official REST API envelope:

{ "code": 0, "msg": "success", "result": { ... } }

Where code: 0 means success.
Source: https://docs.opinion.trade/developer-guide/opinion-open-api

Our Cached Spec

core/specs/opinion/opinion-openapi.yaml (APIBaseResponse schema) correctly models this as code/msg/result. The YAML is accurate.

callApi() References at Risk

None — this exchange does not use callApi(). All HTTP calls in fetcher.ts are direct.

Hardcoded URL Bypasses

All endpoints use direct HTTP calls, e.g.:

• GET ${this.apiUrl}/market/${marketId} at fetcher.ts:309
• GET ${this.apiUrl}/token/orderbook at fetcher.ts:339
• GET ${this.apiUrl}/token/price-history at fetcher.ts:365
• (all other endpoints similarly)

Impact

The runtime fetcher.ts defines OpinionApiResponse<T> as { errno: number; errmsg: string; result: T } and guards with data.errno !== 0. This diverges from the YAML spec. If the live API uses code/msg (as documented), errors will go undetected. If the live API actually uses errno/errmsg (as the code assumes), the YAML spec is the one that's wrong. One of them needs to be corrected to match reality.

---

Found by automated spec drift audit