test: probe Tradernet quote stream causal integrity

[safal207]

Purpose

A bounded, public, unauthenticated causal-integrity audit of Tradernet quote delivery. It reconstructs the historical Done Finance / Tradernet scenarios without repeating mass or stress tests against production.

The causal path under test is:

subscription
→ initial snapshot
→ incremental quote stream
→ controlled disconnect
→ reconnect
→ resubscribe
→ sequence/revision continuity
→ market-time integrity
→ repeated-subscription idempotency

Exact-head execution

• exact audited head: 5f0c82162d6cd37c6971a935c988d5008f34dd43;
• workflow run: 30273235870;
• workflow conclusion: success;
• evidence artifact ID: 8655725085;
• evidence ZIP SHA-256: f644e12816cfed47eb7a7645e4a37fc8044e9db4016a30e692674304a27ba1fc;
• receipt artifact ID: 8655725709;
• receipt ZIP SHA-256: 1b58c8c4eaab25f88acc456bd2dc5930e0c7e8abc96b63cc4428e0e322fb733b;
• manifest SHA-256: 332adb094286b37b1814a661bcec864f5a31d2a62579e541676ec9dd25ea580b.

The manifest binds expected, initial and final source identity to the same exact head and records clean initial/final worktrees.

Finding 1 — reconnect/resubscribe failure not reproduced

The public unauthenticated server opened in demo mode and delivered q events for AAPL.US and MSFT.US before and after one controlled disconnect.

• quote flow worked before disconnect;
• reconnect opened;
• the identical subscription was sent again;
• quote flow resumed for both tickers;
• sequence regressions: 0;
• revision regressions: 0;
• duplicate incremental sequences: 0.

Verdict for this narrow scenario: NOT_REPRODUCED.

This does not prove that server-side zombie connections are cleaned up. That still requires server connection/subscription metrics, generation IDs, heartbeat timeout records and controlled staging tests.

Finding 2 — reproducible temporal data-integrity defect candidate

The expanded causal analysis found a stronger issue that the original reconnect check missed.

Within one ticker stream, n and rev continued to increase, but ltt repeatedly moved backward by approximately 15 minutes.

Exact-head run result:

• temporal contradictions in reconnect audit: 17;
• affected tickers: AAPL.US, MSFT.US;
• every detected backward jump was approximately 15 minutes;
• reproduced before the controlled disconnect;
• reproduced after reconnect/resubscribe;
• repeated in both connection phases.

Examples:

AAPL.US
n 19404 → 19405
rev 50375169 → 50378714
ltt 10:04:14 → 09:49:14  (-900 s)

AAPL.US
n 19406 → 19407
rev 50385148 → 50389138
ltt 10:04:17 → 09:49:17  (-900 s)

A separate repeated-subscription connection contained another 8 approximately 15-minute backward jumps (4 for AAPL and 4 for MSFT), for 25 observed temporal contradictions across three sequential public connection phases.

Verdict: DEFECT_CANDIDATE for quote-stream temporal integrity.

Causal hypotheses

1. Real-time and approximately 15-minute-delayed producers are multiplexed into the same q stream without an explicit source/provenance marker.
2. ltt has different undocumented semantics for different partial-update producers.
3. A client reducer that merges every partial payload by increasing n/rev may overwrite a fresh last-trade time and price with stale values.

User-visible risk

A client may appear healthy — connected socket, increasing sequence and increasing revision — while the visible last-trade time and potentially ltp intermittently roll backward. This is a market-data integrity issue. The evidence does not establish any impact on order execution.

Finding 3 — repeated subscription does not duplicate incremental delivery

On one public connection the exact same two-ticker subscription was sent once and then repeated once after four seconds.

• quote events before repeat: 11;
• quote events after repeat: 22;
• duplicate incremental ticker/sequence pairs: 0;
• both tickers continued to update;
• connection closed normally;
• verdict: NOT_REPRODUCED for duplicate-stream multiplication.

However, the repeated subscription caused the server to resend one init=1 snapshot for each ticker using the current sequence/revision. This appears idempotent with respect to incremental delivery, but a client that sends duplicate subscriptions may still trigger repeated state reinitialization.

Finding 4 — HTTP error semantics remain ambiguous

The legacy unauthenticated getStockQuotesJson requests return HTTP 200 with an application error payload:

{"error":"Invalid credentials","errMsg":"Invalid credentials","code":12}

This is not classified as a security vulnerability. It is an observability/contract smell because status-only health checks can treat an authentication failure as transport success.

The public securities export route works with a literal + ticker delimiter and returned two instrument rows.

Documentation signal

The official Tradernet API navigation still exposes WebSocket real-time quote and market-depth subscription sections, but the WebSocket example page currently displays an example-loading error. This limits the ability to distinguish intended delayed/demo feed semantics from an implementation defect.

Hard boundary

• public and unauthenticated only;
• exactly two tickers;
• one active WebSocket at a time;
• one controlled disconnect and reconnect;
• one repeated identical subscription;
• no market-depth/order-book subscription;
• no portfolio/account access;
• no order entry or financial action;
• no malformed-protocol fuzzing;
• no concurrency, mass subscription or load testing;
• bounded observation duration, message count and bytes.

Claim boundary

The evidence proves that the public demo q stream emitted monotonic n/rev alongside repeatedly non-monotonic ltt values separated by approximately 15 minutes. It does not identify the upstream feed, venue or entitlement source because the payload does not expose explicit provenance. It also does not prove order-execution impact or a server-side resource leak.

Stack

This remains a draft stacked PR and has not been merged.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 6a542327-f26d-4ae5-8f75-8d7631f85f87

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch agent/tradernet-public-quotes-reconnect

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[safal207]

Follow-up causal result is now recorded in stacked draft PR #122.

Exact head 879262b3e14785fdffd6be47867f4cb43a7f7f24, run 30280948711:

• 15/15 materially backward-time q payloads were accepted by a conventional monotonic n/rev shallow-merge reducer;
• all 15 changed ltp and/or lts as well as ltt;
• a provenance-aware freshness guard suppressed all 15 rollback effects;
• two init=1 snapshots after repeated subscription matched current state and were not stale;
• all contradictory updates lacked explicit feed/delay/entitlement provenance.

This strengthens the finding from server temporal inconsistency to a deterministic client-state defect candidate for the tested reducer model. It still does not claim the production Tradernet UI uses that reducer or that order execution is affected.