# Protocol wire facts
Connection, request ids, cancels and end markers. Format: [README](README.md).
### Duplicate client id (326)
*Live 2026-10-26, paper Gateway, server 226; #1091.*
- Connecting with a client id already in use: after `start_api`, TWS sends exactly one frame, a
protobuf Error (msg id 4, request id -1, code 326, "Unable to connect as the client id is
already in use. Retry with a unique client id."). No NextValidId or ManagedAccounts. Socket
closes ~0.7s later.
- A clean drop of the holder frees the id immediately.
- Half-open socket (simulated with a TCP proxy that closed the client side and held the TWS
side 10s): each reconnect attempt got 326 until TWS closed its side, then the next attempt
reconnected. So 326 is transient on reconnect (retry) and fatal on the initial connect.
### Request id range
*Live 2026-09-11, paper Gateway, server 220; #789, #912 (`REQUEST_ID_FLOOR` /
`REQUEST_ID_CEILING` in `src/client/ids.rs`).*
- Data frames (ContractData / End) echo every id tried: 0, 9000, 1<<24, 1<<30, i32::MAX-1,
i32::MAX, -2, -1000, i32::MIN+1, i32::MIN.
- Error frames (code 200) echo all of those **except i32::MAX and i32::MIN**: field 1 arrives
absent, decodes as -1, and the error cannot be routed. An allocator must stop at i32::MAX-1.
- `-1` is IB's NO_VALID_ID sentinel; the C# client does no sign validation.
### Cancel after a request-bound terminal error
*Live 2026-10-26, paper Gateway; #1094, #1097, #1096.*
TWS reply to a cancel sent after the request already failed. Observed while every type still
sent the safety-net cancel; types whose code is verified here now skip it, so the reply no
longer occurs for them.
| market_data, realtime_bars, tick_by_tick | 200 | 300 |
| market_depth | 200 | 310 |
| historical_data (stream / fetch) | 200, 162, 10314 | 366 "No historical data query found" |
| pnl | 321 | 10185 |
| pnl_single | 321 | 10186 |
| scanner | 162 (disabled scan code) | 365 |
| contract_details, historical_ticks | 200 | none |
| account_summary | 321 | none |
- The reply has no recipient; the transport logs `no recipient for error` at INFO. It does not
reach `notice_stream()`. Cost: one wasted write and one log line.
- `positions_multi` / `account_updates_multi`: TWS accepts a made-up account (DU0000000) with
no error, so no terminal error could be provoked.
- 10314 came from a 1975 end date (IB rejects that old a date), not a format problem.
- Skipping the cancel is opt-in per verified code (`StreamDecoder::rejection_ends_request`). A
global skip was rejected: a code we treat as terminal may not end the request at TWS (10197
market data; scanner 165), and skipping would leak TWS resources.
### One-shot requests answer once
*Live 2026-10-26, paper Gateway, off-hours; #1107.*
- `calculate_option_price`, `calculate_implied_volatility`, `head_timestamp`,
`histogram_data`, historical schedule: exactly one frame each, then nothing for 15s. Option
computations do not stream.
- A cancel sent after the answer draws no error (option price, head timestamp, histogram):
harmless, unneeded. The answer acts as a snapshot end.
- **Not probed:** WSH metadata (paper account gets 10276 "News feed is not allowed").
### End markers come after the initial dump only
*Live 2026-10-05, paper Gateway, single account, group "All"; PR #957 review. Diagnostics:
`integration/async/tests/end_markers.rs` (`#[ignore]`).*
- account_summary, account_updates, account_updates_multi, positions, positions_multi send End
after the initial dump only. No End after fill-triggered pushes (~21s, ~61s) or the 3-minute
periodic push (~241s). Never assume one End per push.
- **account_summary sends End twice** (group "All", 3/3 reproductions; recorder showed 1
request, 2 AccountSummaryEnd frames on the wire, so not a routing bug):
- regular tags only: rows, End, End
- `$LEDGER:ALL` only: ledger block, End, the same ledger block, End
- both: rows, ledger, End, ledger, End
- One earlier 30s run showed 1 End, so not fully deterministic.
- account_summary pushes: 111 rows within one second; pushes are ≥40s apart. Pushes include
unchanged values.
- **Open:** after `cancel().await` (cancel frame on the wire with the same id, as in C#), a
third account_summary request on the same connection still got 322 (max 2) 10s later. A fresh
connection per request works. Unknown whether TWS keeps the slot or the cancel is
ineffective.