ws: assert real data on /liquidation/feed live test (backend now replays last N on connect)

[martinkersner]

What

Add a data-asserting live WS test for liquidation_feed (/ws/v1/liquidation/feed) to tests/test_ws_live.py, in the same class as the ticker / premium tests where a quiet window is a FAIL, not a pass.

Today test_ws_live.py has no test for liquidation_feed at all — the channel is exposed by the SDK (datamaxi/aio/liquidation.py, datamaxi/resources/liquidation.py) but untested live, because a fresh connection was not guaranteed to yield any data within a bounded window.

Why now

The backend just changed. Bisonai/datamaxi-backend#7990 (PR #8338, merged as 976b264f5) makes /ws/v1/liquidation/feed replay the last N liquidations immediately on connect, before any live event. A fresh connection now deterministically receives data, so the channel can be asserted end-to-end like ticker.

This closes the gap noted in #181 / PR #182: liquidation_feed was the one channel that couldn't get a real data-assertion test.

⚠️ Blocked on deploy

The backend change is merged to main but not yet deployed. data-api must be rolled out before this test can pass. Don't merge this test until a data-api deploy carrying 976b264f5 is live, or the lane goes red.

Backend contract (as merged)

• Up to N frames on connect, ordered oldest→newest, before any live event.
• N defaults to 5, server-side (LIQUIDATION_FEED_REPLAY_N; 0 disables replay entirely).
• Replayed frames carry "snap": true. Live frames omit the field entirely (omitempty), so live payloads are byte-identical to before the change.
• The channel takes no parameters — no SUBSCRIBE, no symbol/exchange filter. It is an unfiltered firehose across all exchanges/symbols. Just connect.
• A live event may interleave between replayed frames (the backend subscribes before it replays, deliberately, so no event is dropped in the seam). Dedupe on the composite (e, id, q, sd, d) if the test cares — there is no unique per-event id (id is TokenId, the token, not the event).
• A freshly-restarted pod warms its replay ring from ClickHouse at boot, so replay is available immediately after a rollout — no cold-start hole.

Suggested shape

Mirror the high-traffic pattern already used for ticker:

• Connect to liquidation_feed, assert at least one data message arrives well within the timeout (replay is immediate, so this should be sub-second, not _QUIET_TIMEOUT).
• Assert the payload shape: e, d, s, b, q, sd present; d is a plausible UNIX-ms timestamp.
• Optionally assert the first frame carries snap: true, proving it's replay rather than a lucky live event. Note this couples the test to the flag — if LIQUIDATION_FEED_REPLAY_N=0 is ever set in the target env, that assertion fails rather than skips. Decide whether that's desirable (it does catch an accidentally-disabled replay).

Done when

tests/test_ws_live.py has a liquidation_feed test that asserts a real, well-formed data payload on connect, and a quiet window is a FAIL — matching the ticker / premium tests. liquidation_feed is no longer listed among the sporadic / quiet-tolerant channels in the module docstring.

Context

• Backend issue: Bisonai/datamaxi-backend#7990
• Backend PR: Bisonai/datamaxi-backend#8338
• Originating SDK issue: Add live WS test asserting real data on a high-traffic channel #181 (PR test(ws): live ticker data assertion on high-traffic channel (Closes #181) #182)