Fail loud: error #6000 instead of stale data

Out-of-sync DepthCaches return an explicit error, never silently stale data

Id: e325b6fb-117a-4f10-aa63-6d070b01188a Type: decision Status: active Evidence: confirmed Source: code path in packages/ubdcc-dcn/ubdcc_dcn/RestEndpoints.py; present since commit 938eed7, Oct 2024 — i.e. from the LUCIT era already, not a recent addition

When a DepthCacheNode catches UBLDC’s DepthCacheOutOfSync, get_asks/get_bids return error_id="#6000" instead of the last-known (now potentially stale) order-book levels.

Reason: stated explicitly in the README (commit 8490df2): “The cluster either serves consistent data or fails loudly; it never silently accumulates stale levels.” This is the suite-wide fail-loud philosophy applied to the cluster’s public API specifically — a caller getting #6000 can decide to wait, retry, or reduce confidence, instead of unknowingly trading on an order book that looks fine but no longer reflects the exchange.

Rejected alternative (implicit): serving the last-known state while a resync is in progress, to avoid returning errors to callers. Rejected by the same reasoning as the rest of the suite’s fail-loud convention — a plausible-looking but wrong order book is worse than a visible gap.