Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Status: EXPERIMENTAL

Stated here rather than only per-release, because a reader arriving at a specific version needs it as much as one reading the top.

This package has not run in production. While it is 0.x the API may change without a major version. Coverage is uneven by design: the fake and the stubbed HTTP transport are well covered, order placement and authenticated flows are not. Nothing here runs against the live venue — every Webull call is signed, so there is no public endpoint a credential-less repository could test against.

Whenever an endpoint moves to :proven, the entry that does it states the evidence — what was run against the live venue, and when. "Marked proven" with no evidence is not an acceptable changelog line.

[Unreleased]

[0.4.49] - 2026-09-14

Fixed

• A shard whose socket failed to OPEN was never retried — issue #4. The failed-open branch logged one warning and returned {:noreply, state}, so the shard was not merely un-reopened: it was never put in state.shards at all, and handle_info(:resubscribe, _) reduces over exactly that map. Its symbols were orphaned for the life of the process.

  Reported from a real boot under load average 54: three of four shards timed out their handshake and stayed dark for 28 minutes across zero reopen attempts until the node was restarted, with the feed alive and every liveness probe passing. A secondary cost fell on the consumer, whose REST gap-fill saw nothing covered and drew 88 HTTP 429/minute from the venue for the whole 28 minutes.

  The delivery gate added for issue #1 could not have caught this, and should not be widened to: it reopens a shard once no symbol of its has arrived for stale_delivery_ms, and a shard that never opened has never delivered anything to age. "Never worked" is not "stopped working" — two conditions that look alike and want opposite recoveries.

  A failed open is now retried on its own backoff — one second, doubling, capped at a minute — until it opens or a resubscribe fills the slot by its own route. It is also audible: a :coverage_change warning naming the shard fires once when it first fails, and a matching :info once when it opens, rather than a WARN line at boot that nothing revisits. open_retry_base_ms: and open_retry_max_ms: tune it.

[0.4.48] - 2026-09-14

No consumer-facing changes. Internal or packaging work only — recorded so every published version has a heading, because an absent one cannot be told apart from one the release pipeline dropped.

[0.4.47] - 2026-09-14

No consumer-facing changes. Internal or packaging work only — recorded so every published version has a heading, because an absent one cannot be told apart from one the release pipeline dropped.

[0.4.46] - 2026-09-14

Changed

• The test suite runs in 10.3s instead of 25.5s, with the same 836 tests. Nothing was weakened, removed or retimed — two groups of tests moved into files of their own.

  feed_test.exs alone took 24.7 seconds for 94 tests while this package's other 742 tests took 4.5 seconds between them. ExUnit parallelises across FILES and serialises within one, so roughly eighteen seconds of unavoidable waiting — a tick boundary, a deadline expiring, a call proving it outlasts GenServer.call/2's five-second default — ran end to end in that one file while everything else finished in its shadow.

  Two coherent groups moved out: the issue #3 tick/deadline/answer identity tests (resubscribe_identity_test.exs) and the busy-feed timeout test (busy_feed_test.exs). Both carry a moduledoc saying why they are separate, so the next person does not fold them back in.

  The margins were not touched. Every one of these tests waits on a real timer, and shrinking the waits to buy speed is how a suite becomes flaky under load — which this family has already paid for three times. The saving comes from letting the waiting overlap, not from waiting less.

  Measured rather than assumed: dp_exchange_coinbase has the same amount of slow waiting (14.4s of a 17.6s suite) and did not need this, because its slow tests already live in three different files.

[0.4.45] - 2026-09-13

Changed

• delegation_test.exs claimed "every facade function reaches the venue" while covering seventeen of them. Five were missing: get_trades/2, quantization/2, get_fees/2, adjusted?/1 and live?/1. The moduledoc now says what it covers, and the five have their own describe so the gap is legible rather than absorbed.

  The file's own reasoning is why this matters: the facade threads credentials and the rate limiter into each call, and "a function wired to the wrong Rest arity — or wired without with_limiter/1 — compiles, type-checks and then either loses the credential or bypasses the limiter".

  A refusal-shaped assertion cannot catch that, which is worth recording because it was the first thing tried: get_trades/2 and get_price/2 both answer {:error, {:missing_credentials, :webull}} before a request is built, so swapping one delegate for the other left the test green. Only a happy path whose result differs pins the target. All three wrong-delegate swaps now fail.

  Two of the five corrected a wrong assumption rather than the code: get_fees/2 answers without credentials, because this venue's crypto fee is a flat published rate rather than an account query; and the environments are :production and :uat, not :live/:paper, which Environment.validate!/1 refuses outright rather than defaulting.

  Coverage 91.87% to 92.14%.

[0.4.44] - 2026-09-13

Changed

• The weekly endpoint-index check fired for the first time, and its finding is recorded rather than rubber-stamped. broker-fd-api/order-executions is a new page in the vendor's sitemap since the 2026-09-09 capture, taking that surface from 79 to 80.

  No claim in this package changed. The Broker API is a different product tier from the Trading + Market Data API every callback here is built on, and endpoint-inventory.md puts this package's coverage of it at 0. The nearest-sounding claim — {:get_trade_volume, 2} declared :unsupported — rests on the venue publishing no account volume report, not on the absence of an executions endpoint: "the venue reports fills, and summing them here would be this package's arithmetic rather than the venue's ledger". A broker-tier executions page does not supply that ledger.

  The capture is re-dated to 2026-09-13 after that analysis, in the order check_endpoint_inventory.sh asks for — it warns that updating the capture first "turns this check into a rubber stamp", and the reasoning now lives in the file's own header so the next person diffing it can see what was decided and why.

  Found by running the checker by hand the day before its first scheduled Monday. All fourteen weekly checks across the family had never once executed — they were added on Monday 2026-09-08 at 12:58 UTC, after that day's 09:00 trigger — so the first real run would have been their first run, on jobs that are deliberately non-blocking and therefore fail quietly. Every one was exercised: six dependency-floor checks pass, five doc-source checks resolve all 32 cited URLs, and of the three index checks this was the only one with anything to say.

[0.4.43] - 2026-09-13

No consumer-facing changes. Internal or packaging work only — recorded so every published version has a heading, because an absent one cannot be told apart from one the release pipeline dropped.

[0.4.42] - 2026-09-13

No consumer-facing changes. Internal or packaging work only — recorded so every published version has a heading, because an absent one cannot be told apart from one the release pipeline dropped.

[0.4.41] - 2026-09-13

Fixed

• usage-rules.md said venue_time is never nil on this venue and called a nil branch "dead code". That was true until 0.4.36 and 0.4.37, when the REST quote, the REST order book, and the MQTT quote and book stopped discarding real prices and real levels over a time the venue had not stated — and the documentation did not follow. usage-rules.md is what a consuming agent reads, so a consumer taking that advice had a latent crash on a field this package had started returning.

  It now says the opposite, and says what has not changed: the local clock is never substituted into venue_time. The "Timestamps come from the venue, or the call fails" section is rewritten to split by TYPE rather than assert one rule — a Candle, VolumeProfile or Trade is still refused undated because each enforces its time, while a Quote or OrderBook is delivered with venue_time: nil because neither does.

Changed

• usage-rules.md now states the order-book ordering guarantee from 0.4.39 and the identity-drop behaviour from 0.4.38 — including that a shorter screener list is not an error and that a dropped row leaves a gap in rank rather than renumbering the survivors. Both were consumer-visible changes that shipped without a consumer-facing note.

[0.4.39] - 2026-09-13

Fixed

• get_order_book/2 returned the venue's row order, so hd(bids) was not the best bid. Core.Types.OrderBook makes this part of the contract and anticipates the mistake by name: "The ordering is part of the contract, not a convenience: a caller reading hd(bids) as the best bid is reading it correctly, and a venue package that returns venue-order without re-sorting has broken the contract even though every value in it is true."

  A consumer pricing against the top of this book got whatever row the venue happened to send first — a wrong best bid made entirely of real numbers.

  dp_exchange_coinbase was the one package in the family already sorting, so the family had both answers running at once. The sort matches its sorted/2, including {direction, Decimal} rather than term order, because Decimal structs do not compare correctly as plain terms. The not is_nil(price) filter this decoder already had is what keeps a nil price from reaching the sort.

[0.4.38] - 2026-09-13

Fixed

• A row the venue did not identify was published with an empty id or symbol. Core.Types.Watchlist, NewsItem and ScreenerResult each enforce their identifying field and new/1 refuses a nil there, but these build the struct literally — as everywhere in this family — so || "" satisfied the requirement while saying nothing.

  An empty string is worse than the nil it replaced. A nil is detectable; "" is a value, so a consumer keying coverage by symbol gets a live entry named "", and one deduplicating by id collapses every unidentified row into a single entry.

  The news fallback was the worst of the three: value(row, ["id", "news_id"]) || value(row, ["symbol"]) || "" published a ticker symbol as an item id. That looks like an id and collides for every item about the same symbol, so a consumer deduplicating by id silently kept one story per ticker.

  All three now drop the row — the rule dp_exchange_robinhood already states for the same situation: "a row missing symbol entirely is dropped rather than published under a fabricated one … a nil key there is worse than one fewer row this cycle". The screener drops after Enum.with_index/2, so a survivor keeps the position the venue returned it in; closing the gap would re-rank the list, which that field's own comment rules out.

  get_watchlist/3's value(row, ["watchlist_id"]) || watchlist_id is unchanged and is not the same shape: it falls back to the id the caller asked for, which is neither absent nor fabricated.

  Found by a mechanical audit of every literal struct construction in the family against the fields its Core type requires non-nil — the check new/1 performs and 85 literal constructions bypass.

[0.4.37] - 2026-09-13

Fixed

• A REST quote or order book the venue did not date was refused outright. get_price/3 and get_order_book/2 gated on {:ok, timestamp} <- venue_time(row), so a row without a readable time discarded a real guarded price, or a whole set of book levels, over a field neither type enforces. Core.Types.Quote lists [:symbol, :price, :observed_at, :provider]; Core.Types.OrderBook lists [:symbol, :bids, :asks, :observed_at, :provider] and types venue_time as DateTime.t() | nil.

  top_of_book_time/1 in this same module has always answered the other way for get_top_of_book/3 — the sibling call on the same endpoint — so two calls reading the same rows disagreed about whether an undated one was usable.

  The guarantee those tests were named for ("not stamped with the local clock", "rather than substituting now") is unchanged and is now asserted directly rather than inferred from an {:error, _}, which could not tell a nil apart from a substitution in the first place.

  Three paths still refuse, and that is the contract deciding, not inconsistency: get_historical_prices/5 builds a Candle and get_volume_profile/4 a VolumeProfile, both of which enforce :opened_at — an interval at an invented minute is a different kind of wrong from an unstated timestamp — and get_trades/2 builds a Trade, which enforces :timestamp.

  Completes the sweep that began in dp_exchange_gemini and reached dp_exchange_schwab; this was the last venue and the last transport carrying it.

[0.4.36] - 2026-09-13

Fixed

• A streamed book or quote the venue did not date was dropped entirely. emit_top_of_book/2 and emit_decoded/2 gated on venue_time/1, whose comment read "on a stream, refusing to substitute means dropping the frame rather than stamping it with our own clock". Refusing to substitute is right; that was not it. Writing our own clock into venue_time would be the substitution, and emitting nil there is its opposite.

  Core.Types.TopOfBook enforces [:symbol, :observed_at, :provider] and Core.Types.Quote [:symbol, :price, :observed_at, :provider]. Neither enforces the venue's time, and observed_at — always present, documented as "a different, honest fact" rather than a stand-in — is what states freshness. A real bid, ask or traded price was discarded over a field the contract marks optional.

  This package's own REST arm has always answered the other way: Rest.get_top_of_book/2 reads the time through top_of_book_time/1, which returns nil when venue_time/1 fails. Same venue, same type, opposite answer decided by transport — and Rest.venue_time/1 already carried its own note that an incomplete key list "silently produced :missing_venue_timestamp for every row until they were added", which is this same failure having happened once before on the other side.

  emit_trade/2 still gates on venue_time/1, and that is not an inconsistency: Core.Types.Trade lists :timestamp in @enforce_keys and types it non-nullable, so a print this package cannot place in time is genuinely not one it can report. The answers differ because the contracts differ.

  Found by sweeping the family after the identical defect in dp_exchange_gemini, where the same sentence appeared in the same role.

[0.4.34] - 2026-09-13

Fixed

• A streamed TopOfBook reported bid_size and ask_size as nil while the venue was sending them. Socket hardcoded both to nil under a comment stating as fact that "the venue's book message carries prices and no sizes". The venue's own protobuf schema, kept verbatim in docs/reference/webull/streaming-api.md, is AskBid { string price = 1; string size = 2; } — and QuoteProto was already walking field 2 off the wire in decode_message/1 before level_price/1 threw it away. The test fixtures in this repo have been building levels with sizes all along.

  Core.Types.TopOfBook is explicit that a nil size "means 'not published', never 'none available'", so a consumer sizing an order against the top was being told the depth was unpublished when it had been published and discarded. Both sizes now reach the consumer. A level that states no size is still nil; one that states "0" is a zero, because that is what the venue said.

  Found while sweeping the family after the same class of defect in dp_exchange_schwab (a Change-delivery delta published as a book). Webull's quote topic is not a delta stream — its schema carries no sequence number and no operation field, so each message must stand alone — and needs no merge. This was the other half of the same read.

Changed

• usage-rules.md records that streamed sizes are now populated, and what a nil there means.

[0.4.32] - 2026-09-13

Fixed

• A caller parked on a shard reopened for INVALID_SESSION was never answered. It waited out @call_timeout and then EXITed, taking the calling process with it — the outcome this module's own comments name as the one to avoid.

  complete_link_up/3 calls handle_subscribe_result/3, then reads the shard back and treats a missing one as a caller already dealt with. That was true while isolate_crashed_shard/3 was the only thing that could remove a shard mid-reply. It stopped being true when rebuild_stale_shard/3 was added — on the line immediately above that read — because it deleted the shard on INVALID_SESSION without answering anyone, and the comment asserting the invariant is what kept it from being noticed.

  The reachable path is ordinary: a caller subscribes to symbols landing on a shard that is still connecting and is parked in reply_to; the shard links up; its replay subscribe is answered INVALID_SESSION.

  Both teardowns now answer through one funnel, answer_parked_caller/2, rather than each writing the reply out for itself — the two drifting apart is the whole of what went wrong, since both delete a shard and only one remembered what that means for a caller. The parked reply's capacity overflow travels with the failure here exactly as it does everywhere else. A caller on this path now gets {:error, {:invalid_session, session_id}}, or the {:partial_failure, ...} shape when it also had symbols that did not fit.

[0.4.31] - 2026-09-13

Fixed

• A superseded reconcile's answer could still settle its successor's tag (issue #3, follow-up). 0.4.29 tore a superseded attempt down, and the comment there claimed that was what stopped its stale result reaching the successor's callers. It is not, and the claim has been corrected in place. An answer already in the mailbox cannot be recalled by killing the process that sent it — send/2 completes before the kill does — so an attempt that answers between its successor's trigger arriving and that trigger being processed has already left its result behind. Routed by tag alone, that stale result forgot the successor, demonitored it and dropped its bookkeeping, and was then handed to the successor's callers as theirs.

  An attempt now has an identity that its answer carries, not just its deadline: a {:reconcile_done, tag, attempt, result} is routed only when the tag is still tracking that attempt. The deadline matches on the same token rather than on the monitor ref, so there is one notion of attempt identity in the module instead of two.

  Also settled by the same check: an answer arriving after its tag's deadline has already fired is now dropped rather than applied. A deadline reported as :no_venue_response is not retracted by the answer turning up afterwards — the caller has been answered and the failure counted, and applying the late result would un-count it, making a shard that is reliably too slow indistinguishable from a healthy one. One attempt gets one outcome, and the first thing to conclude it is the one that counts.

  No change to any error shape a caller sees. The synthesised {:reconcile_done, tag, result} that the deadline and :DOWN paths dispatch is unchanged and does not pass through the new check — those have already decided the outcome.

[0.4.29] - 2026-09-13

Fixed

• A blind resubscribe could not complete once a shard needed it, because the next tick killed it (issue #3). @resubscribe_interval_ms and @reconcile_timeout_ms are both 60,000, and handle_info(:resubscribe, _) re-arms its own timer before spawning — so at every tick boundary the tick was enqueued ahead of the deadline armed during the previous one. The tick overwrote reconciling[{:resubscribe, index}] with a fresh task, and the previous deadline then found that successor under the tag it had been armed for and killed it milliseconds old.

  The blind re-issue is the only recovery this venue has for a session it has silently stopped publishing to (see the moduledoc and DpCryptoManagement's issue #17), so once a shard stalled it could not come back except by escalation. The reported boot measured 449 reconcile timeouts producing 12 recoveries; a four-shard, 60-second interval over 2h04m predicts 496 ticks, so very nearly every tick was failing this way.

  Two fixes, because this was two defects wearing one symptom:

  • A tick whose previous attempt is still in flight is now skipped. A second identical subscribe for a session the venue has not answered for yet is load, not a safety net — validate_resubscribe_interval_ms!/1 already refuses a configured interval under a second in those words, and an unfinished attempt shortens the effective interval just as surely. Consequence worth knowing: a shard whose attempt is hung re-asserts on the tick after its deadline clears, which — the deadline and the interval being equal — is every other tick. Stated rather than tuned away, because @reconcile_timeout_ms is derived from @call_timeout for reasons unrelated to this timer.
  • A deadline now names the attempt rather than the tag it ran under. The timeout message carries the attempt's monitor ref and is ignored unless the tag still holds it, so a timer can only ever tear down what it was armed for. This also covers {:link_up, _} and {:background, _}, where a supersede is legitimate.

  Relatedly, spawn_reconcile/3 now tears an attempt down when it supersedes one instead of orphaning it. An orphan's monitor ref belonged to nothing, so its :DOWN reached drop_dead_subscriber/2 as though a subscriber had died; and if it later answered, the {:reconcile_done, tag, _} clause forgot its successor and handed that successor's callers a stale result.

  No change to any error shape a caller sees.

Changed

• The test named "the resubscribe timer reschedules itself" now drives the feed's own timer instead of hand-sending :resubscribe twice. The hand-sent version tested that the handler can run twice — not what it was named for — and passed only by racing the first attempt's reply back to the mailbox, which is the overlap issue #3 turned out to be about.

[0.4.28] - 2026-09-12

Fixed

• A timed-out reconcile no longer puts an ERROR-level OTP report on the host's logger (issue #2). The reconcile task was torn down with Process.exit(pid, :kill), which reaches its Task.Supervisor as :killed; OTP skips its child-termination report only for :normal, :shutdown and {:shutdown, _}, and reports every other reason at ERROR. So each timed-out reconcile — one per shard per resubscribe tick — logged Child :undefined of Supervisor #PID<_> (Task.Supervisor) terminated / ** (exit) killed. The reporting host saw 234 of 239 ERROR lines in a single boot from this alone.

  Now :shutdown, which terminates the task identically (no reconcile task traps exits) and is the reason OTP reads as intentional. This is the same choice stop_socket/1 already made for the websocket, made there and never carried to the task.

  Nothing was broken by the noise and no caller-visible behaviour changes: the timeout still answers its caller with {:error, {:reconcile_timeout, ms, :no_venue_response}}, and the condition is still reported at WARN with the shard named. What changes is that ERROR on a host running this package now carries information again — the OTP report named neither this package nor the shard, and arrived at the level alerting keys off.

  Measured rather than assumed, on 2026-09-12: a Task.Supervisor child was exited both ways with Logger's :logger_translator primary filter set to sasl: true (the host setting that lets these through; this package's test env drops them). :kill produced the report above; :shutdown produced nothing. The regression test asserts the task's exit reason, which is the whole of what OTP branches on.

[0.4.27] - 2026-09-12

Fixed

• The escalation added in 0.4.25 made things worse, and is now gated on delivery (issue #1). That version reopened a shard's socket after twelve consecutive blind resubscribe failures. Measured on the reporter's live fleet: three shards hit the limit, reopened, and failed the identical reconcile on the very next tick and every tick after — a fresh session did not change the outcome once — while this venue's coverage fell from 226 distinct symbols to about 160 (−29%), with dp_exchange_coinbase and dp_exchange_gemini flat across the same windows. And because rebuild_stale_shard/3 resets the counter, it had become a cycle: fail twelve times, reopen, fail twelve times, reopen.

  The inference that failed was ours: that a shard which cannot reconcile is a shard whose session is no good. It is not. A reconcile is a subscription-management call, and it can keep failing while the transport underneath streams everything already subscribed to — which is exactly what this package's own log line has always promised, "its N symbol(s) stay on whatever they last delivered until the next resubscribe tick". A reopen breaks that promise.

  The reopen now also requires that none of the shard's symbols has arrived for stale_delivery_ms (five minutes by default, five whole resubscribe cycles). While a shard is still delivering, failures are counted and reported and nothing is torn down: the worst case of doing nothing is a stale subscription set, and the worst case of acting is losing live data. A reopen can only gain something once the shard has gone quiet.

  Five minutes because a shard carries on the order of a hundred symbols, and the question is not whether one symbol has been quiet — an illiquid pair can go minutes without a print — but whether every symbol on the shard has been quiet at once, which a live shard does not do. Tunable via stale_delivery_ms:, alongside resubscribe_failure_limit:.

[0.4.26] - 2026-09-12

Fixed

• A position row the venue did not attribute to an instrument was reported as a position. Core.Types.Position enforces :symbol and its new/1 refuses a nil there, but this decoder builds the struct literally — as every decoder in this family does — so that check never ran and the symbol came through by key. A position naming no instrument cannot be sized, closed or reconciled by anyone: it is not a weaker claim about what is held, it is not a claim at all, and it sat in a list of real positions looking like one.

  One unattributable row now refuses the whole reply rather than being dropped. A position list with an entry silently missing reads as "you hold none of that instrument", which is a different and more dangerous claim than "this response could not be read".

• A reconnect-timing test failed under load while the behaviour was correct. It asserted the attempt-1 path returns in under 500ms, which is stricter than the claim needs — the claim is "no backoff was applied", and the smallest backoff is a full second, so any time under one proves it. Measured against that boundary now. Same shape as the rate-limiter bucket race and Core.PollingFeed's poll-interval waits: a timing assertion that holds when the machine is quiet and inverts when it is not.

[0.4.25] - 2026-09-12

Fixed

• A shard could retry the identical failing resubscribe forever (issue #1). After a node restart, all four shards failed their blind resubscribe with {:reconcile_timeout, 60_000}. Three recovered on their own within eleven minutes; the fourth failed the identical reconcile 21 consecutive times over 21 minutes and never recovered. Nothing counted, so nothing could notice — state.resubscribe_failed was a MapSet, which answers "is this shard failing?" and never "for how long".

  After twelve consecutive failures a shard now reopens its own socket on a fresh session instead of attempting the same reconcile again. The escalation is not new machinery: rebuild_stale_shard/3 already stops the socket, drops the shard's bookkeeping and reopens it, and is what {:invalid_session, _} has always done. A repeated timeout now reaches the same remedy, because after a dozen identical failures "this shard's session is no good" is a better hypothesis than "the next attempt will differ".

  Twelve is measured, not picked. In the reported incident the three shards that self-healed did so after 8, 10 and 10 consecutive failures; a lower limit would tear down sockets that were about to recover, and every teardown claims a fresh session against the venue's per-account ceiling — the same contention that caused the incident. Overridable via resubscribe_failure_limit:, because one incident is one sample. A success resets the count, so only consecutive failures escalate.

Changed

• {:reconcile_timeout, ms} is now {:reconcile_timeout, ms, :no_venue_response} (issue #1). The third element is a statement of fact rather than a guess: that clause runs only because the deadline arrived with no answer.

  It exists because the two causes call for opposite actions — a venue refusing because another session holds the permission must be waited out, since reconnecting claims a further session against the same ceiling, while a wedged socket of ours must be reconnected. A venue that answers with a refusal reaches a caller as that refusal and never as this tuple, so the two are now distinguishable without either being inferred.

  A consumer matching the old two-element tuple must widen the match.

[0.4.24] - 2026-09-12

Changed

• usage-rules.md documents the error shapes this package started returning this week. Several calls that used to answer {:ok, _} with a value a consumer could not act on now refuse instead, and none of those refusals had reached the document a consuming agent actually reads. CLAUDE.md is explicit that usage-rules.md "is not optional and it is not the README", and shipping the behaviour without it left a consumer to discover the new shapes from a crash.

  A consumer matching only {:ok, _} needs no change. One that enumerates error reasons now has them, each with whether retrying is worth anything — which is the part that decides what a caller does next, and the part a bare list of atoms would leave out.

[0.4.23] - 2026-09-12

Fixed

• mix.lock moved to dp_exchange_core 0.3.10. It carries two conformance-suite consolidations and two test-isolation fixes in Core's own suite; for this package the effect is that every fake call the contract suite makes now builds its arguments through one builder, so this venue's endpoint_opts and endpoint_symbols reach all of them rather than only the call sites that happened to be wired. mix.lock is committed and CI honours it, so the pin allowing the newer Core was never the same thing as running it.

[0.4.22] - 2026-09-12

Fixed

• Two conformance assertions were inert here, and are not any more. Core's assertions 14 (get_top_of_book/2 returns a TopOfBook with a DateTime observed_at and no price field) and 23 (Quote/OrderBook carry the venue's own time or nil, never an unparsed stand-in) both called this package's fake with no credential — those endpoints are public-SHAPED, so a credential can only travel in opts, and nothing put one there. This package answered {:error, {:missing_credentials, _}} and the assertions' skip-on-refusal clause took that for an answer.

  Measured: with a fake deliberately returning observed_at: nil — the exact defect assertion 14 exists to catch — this package's contract suite passed clean against Core 0.3.8. Against 0.3.9 it fails, on exactly the endpoints capabilities/0 declares active. Locked forward accordingly; mix.lock is committed and CI honours it, so the pin allowing the newer Core was never the same thing as running it.

• The order-book assertion could only ever see a refusal here. This venue serves an order book for US stocks and ETFs and refuses one for a crypto pair, and every entry in the contract test's sample_pairs: is crypto. endpoint_symbols: (new in Core 0.3.9) now names a symbol the endpoint actually serves, so assertion 23 runs against a real book instead of skipping. The crypto refusal is still correct and still covered — order_book_test.exs asserts it directly.

[0.4.21] - 2026-09-12

Fixed

• mix.lock moved to dp_exchange_core 0.3.8, so assertion 24's refusal check runs here. 0.3.8 stops that assertion accepting a refusal from an endpoint capabilities/0 declares active — the clause that let three packages pass an assertion which never executed on them. The pin already allowed the new Core, but mix.lock is committed and CI runs mix deps.get, which honours it: "the pin allows it" and "CI resolves it" are different statements and only the second one decides what actually runs.

[0.4.20] - 2026-09-12

Fixed

• This package was passing fake-driven conformance assertions that never ran. Several assertions in Core.AdapterContract call an active endpoint through this venue's fake, and every account-scoped one was refused for the missing account before it reached the behaviour under test. The suite took that refusal as a legitimate answer and skipped — green, and proving nothing.

  Caught by deliberately breaking this package's fake against Core's new assertion 24 (a Balance must name the asset it is a balance of): the suite stayed green. It was never confined to 24 — assertion 17, the credential gate, had been passing for the wrong reason, getting its expected failure from the absent account rather than from the stripped credential it exists to test.

  The contract test now declares endpoint_opts:, Core 0.3.7's new option, naming the option each of this venue's own endpoints needs. Verified the way the gap was found: with the fake broken on purpose, the suite now fails.

[0.4.19] - 2026-09-11

Fixed

• The socket reconnected with no delay, forever, against a venue that would not have it back. handle_disconnect/2 returned {:reconnect, state} unconditionally, and websockex supplies no delay of its own: on_disconnect/5 in deps/websockex/lib/websockex.ex calls open_connection/3 and, on failure, calls itself with attempt + 1 — a synchronous loop with nothing between the turns. Verified in the dependency's source, not assumed.

  So any refusal that does not fix itself by being retried sooner — a credential the venue has stopped honouring, an IP it has started refusing, a maintenance window, a 503 — became a connect storm at full speed for as long as it lasted. CLAUDE.md's testing tiers already say what a venue does about traffic like that: "a venue that sees a package polling it on a timer will rate-limit or block". A reconnect storm is that, without the timer.

  dp_exchange_schwab was the only package in the family with reconnect backoff, and its moduledoc had described this exact hazard, in these exact terms, the whole time.

  The attempt counter was in the argument all along. This module used to state that it "keeps no attempt counter", and declined to emit Core.Telemetry.link_reconnect_attempt/3 rather than invent one — refusing to invent was right, and the premise was wrong. attempt_number is a documented key of the connection_status_map that handle_disconnect/2 already pattern-matches on, incremented by websockex for each consecutive failed reconnect and reset each time a live session drops. Backoff and telemetry now both run on it: attempt 1 still reconnects at once, every attempt after doubles from 1s, capped at 30s.

• The backoff arithmetic crashed during a long storm — the one thing it existed to survive. min(base * round(:math.pow(2, n)), max) raises ArithmeticError once the exponent passes 1023, because the float range ends at ~1.8e308, and clamping the result does not help when the raise happens while computing the argument to min/2. At the 30-second cap that is roughly 8.5 hours of continuous failure — an ordinary overnight outage — and the crash lands inside handle_disconnect/2, where it reads as this socket's fault rather than the venue's. Now Bitwise.bsl/2 with the exponent clamped before the shift: no ceiling, exact, and every clamped value gives the identical answer since the cap is already reached at exponent 5.

[0.4.18] - 2026-09-11

Fixed

• A balance the venue did not attribute to an asset was returned as success. Core.Types.Balance's new/1 refuses a nil in :currency, and this decoder never called new/1 — it builds the struct literally, as all five venue packages do, 85 call sites between them — so the check never ran and the field came straight out of the venue's JSON by key. A renamed or absent key produced %Balance{currency: nil}: an amount attributable to no asset, inside {:ok, balances}, which a consumer cannot size, book or reconcile against. It is precisely the renamed-field scenario Core.Types.Validate's moduledoc was written for, arriving through the one path that bypassed the constructor written to catch it.

  Such a row now refuses the whole reply rather than being emitted or silently dropped — dropping it would read as "you hold none of that asset", a different and more dangerous claim than "this response could not be read".

  :balance is deliberately not guarded the same way. Core.Types.Balance now states that it may honestly be nil while :currency may not, and the two are not the same kind of required: an unknown quantity is still a balance, an unattributable one is not.

[0.4.17] - 2026-09-11

Fixed

• subscribe_notices/2 could kill the caller for asking during trouble. It was the one public call in Feed left on GenServer.call/2's five-second default timeout. Every sibling call — subscribe/3, unsubscribe/2, update_symbols/2, coverage/1 — is given @call_timeout, which is this package's own statement of how long the feed may legitimately take to answer on a busy mailbox.

  A consumer registers for notices at start-up, which is precisely when that mailbox is deepest: the transport is coming up, symbols are being resolved, and the handler itself may replay a notice to the newly-registered subscriber. A GenServer.call/3 timeout exits in the caller, not in the feed — so the channel a host uses to hear that something is wrong was the one call that could take the host's calling process down for asking under exactly the conditions it exists to report.

  Now uses @call_timeout like every other call. The test blocks the feed's own process for six seconds — past the old default, nowhere near the new timeout — and asserts both that the call succeeds and that it genuinely queued behind the block, so it fails on the unfixed code rather than passing for free.

[0.4.16] - 2026-09-11

Fixed

• A 200 this package could not decode became an empty object, and then an empty everything. decode/1 collapsed any unparseable body to %{}. %{} is a map, so it passed straight through the readers and came out as a well-formed struct with every field nil, returned as {:ok, value}.

  There was already a test for this — "a non-JSON body decodes to nothing rather than crashing" — and it passed, which is why the defect survived: its name described the substitution, and it only held because get_price/3's reader rejected %{} for carrying no price. Readers whose fields are all optional, like the order and balance ones, accepted the same %{} and answered {:ok, value}.

  oauth_token/3 was the sharpest instance. decode_map/1 returned %{} for a body that was undecodable or not an object, so a token exchange that had not returned a token reported {:ok, %{}} — success. The failure then surfaced at the next signed call as an authentication error, with nothing tying it back to the refresh that caused it.

  The realistic source is not malformed JSON from Webull. It is a 200 that never reached Webull: an interstitial, a captive portal or a CDN maintenance page, each of which answers 200 text/html.

  Success bodies now refuse with {:error, {:undecodable_response, :webull}}, and a token response that decodes but is not an object refuses with {:error, :unexpected_response_shape}. Refusal bodies keep the lenient decode on purpose — a 4xx is read for a human-readable reason, the status code has already established the refusal, and {:venue_error, status} stays true whether or not there was a reason in the body.

[0.4.15] - 2026-09-11

Added

• script/check_doc_sources.sh now reports the age and provenance of this package's own capability claims. capabilities/0 carries measured_at and measured_against because CLAUDE.md is explicit — "Declare what you measured, not what you assume. If it was measured, say when and against what." Both were populated and nothing read them: not the weekly checker, not a test, not a line of consumer documentation.

  That is the same shape as the MANUAL documentation rows before they were aged — a claim that quietly gets old while still reading as current. The check reports the age against the same STALE_DAYS threshold, and reports a missing measured_against as its own finding, because half the rule is not the rule.

  Reported, never enforced. A stale measurement is not a build failure; it is a venue nobody has re-checked, and only a person re-measuring can fix it.

• usage-rules.md tells consumers those fields exist and what to do with them. They ship inside the Hex tarball and are what a consuming agent reads, and none of the five mentioned provenance at all. The distinction worth acting on is not the date but measured_against: a figure measured live against the venue's API and one read off a documentation page and never probed are different kinds of claim, and this package's declarations contain both.

Fixed

• The first version of that check would have reported MISSING on every venue, forever. It grepped for measured_against: "…" on one line. Every venue in this family states the field as a multi-line <> concatenation, because the honest answer is a paragraph — which documents, which endpoints, measured live or read from a page. A single-line grep matches none of them.

  Recorded rather than quietly corrected, because the same mistake was made twice in the same hour: the reading that produced the check also concluded measured_against was unset across the whole family, and came within one commit of replacing five accurate provenance statements — including this one's — with a flat "not probed against the live API". For dp_exchange_gemini that would have been false: its statement records timeframes and candle windows measured live against api.gemini.com. A checker that cannot see a value is not evidence the value is absent.

  The field is now detected by presence and reported as a file:line pointer rather than quoted. These statements run to a paragraph each and the clause that matters is rarely the first one, so an excerpt in a weekly notice would mislead more than it informs.

[0.4.14] - 2026-09-11

Fixed

• A refused MQTT CONNACK stranded the subscribe/2 caller, and a revoked App Key produces one on the very first call. subscribe/2 on a shard that is still connecting parks the caller in shard.reply_to and waits for on_link_up/2. A CONNACK carrying 3, 103 or 104 (credentials rejected) or 105 (five concurrent connections per App Key) means that link_up is never coming — the socket stays connected?: false — and nothing answered the caller. It waited out @call_timeout and then exited, taking the calling process with it. So a consumer with a bad key got a crash instead of {:error, ...}.

  This is the most reachable stranded caller found in this sweep: it needs no failure at all beyond a wrong credential. Verified by driving it — after a refused CONNACK, reply_to was still set and connected? still false, with nothing left that could ever change either.

  The caller now gets {:error, {:connection_refused, details}}, carrying the venue's own CONNACK code and, for 105, reason: :connection_limit. A caller has to tell "rotate the key" from "you already hold five sessions" — reporting a limit breach as rejected credentials is the exact confusion Socket's own comment warns about, one layer up.

• Those refusal notices did not carry a session_id, so a multi-shard Feed could not tell which shard the venue had refused. :link_up and :link_down carry one precisely so it can. The three CONNACK-refusal notices did not, and that omission is why nothing could answer the parked caller. They were the same event class all along; only the successful one had been wired up.

• A CONNACK that never arrives is now bounded too. Socket's :socket_connect_timeout and :socket_recv_timeout cover the TCP connect and the HTTP upgrade; once the WebSocket is up, websockex simply waits for frames, so a venue that accepts the connection and then says nothing left the caller waiting with nothing to react to. @connack_timeout_ms bounds it — derived, not picked: two thirds of @call_timeout, because a deadline at or past the caller's own gives up after the caller has already gone. Keyed by session_id as well as shard index, so a timer armed for one attempt cannot answer a caller parked on the shard that replaced it.

  The socket is left running in both cases. websockex reconnects on its own schedule and a later CONNACK may well succeed — a rotated key, or a concurrent session that has since expired. What must not persist is the caller's wait, not the connection attempt.

[0.4.13] - 2026-09-11

Fixed

• A control-plane reconcile task that died or hung left its caller with no answer at all. Task.Supervisor.start_child/2 gives a child that is neither linked nor monitored, and the reconcile's tag carries the caller's from on the primary path. So a lost task sent no {:reconcile_done, ...}, nothing here learned of it, and that caller waited out @call_timeout and then exited, taking the calling process with it.

  The task is now monitored and bounded. A :DOWN or a timeout is synthesised into the ordinary {:reconcile_done, tag, {:error, _}} shape and re-dispatched, so the caller and every retry ladder are answered exactly as they would be for a reconcile that failed by replying — a task that failed by dying is not a different kind of failure, and giving it its own path is how the two drift.

  Less severe than the sibling wedges fixed the same day in dp_exchange_schwab and dp_exchange_coinbase, and the difference is worth stating. This venue has no "already in flight, join the queue" guard on the primary path, so each subscribe spawns its own reconcile and a lost task strands exactly one caller rather than every future one. Bounded — and still a caller that never gets an answer.

  @reconcile_timeout_ms is @call_timeout * 4, deliberately above the caller's own deadline: a reconcile that outlives the caller waiting on it has already lost that caller, and firing sooner would only replace one lost reply with another while the request was still in flight. The task body is an HTTP round trip through Core.HttpClient, which carries its own per-attempt timeout and retries; this is the outer bound for a task that has stopped answering entirely.

  One :DOWN clause now serves both this and the subscriber-pruning added last release, because Elixir takes the first matching clause and there is no falling through — the monitor ref decides which.

• A racy test in socket_malformed_close_test.exs, which CI caught and six local runs did not. The fake server closed the TCP connection in the same breath as sending the malformed close frame, so the FIN could reach the client and be observed before WebSockex had parsed the bytes ahead of it — and handle_disconnect/2 then reported %WebSockex.ConnError{original: :closed} rather than the FrameError the test exists to pin.

  The server now blocks on a read and closes only after the client tears the connection down, which is the event the assertion is actually waiting for. Not closing at all was tried first and is wrong: no disconnect fires, because it is the client's own reaction to the bad frame that ends the connection.

  Worth recording because of where it showed: green on every local run, red in CI, where fewer cores and max_cases: 8 change the interleaving. Reproduced locally by passing --max-cases 8, then six clean runs at that concurrency.

[0.4.12] - 2026-09-11

Fixed

• A dead subscriber's pid was never removed, and the fan-out walked it on every message for the life of the feed. Core.Fanout.resolve/1 skipped a dead subscriber at send time, so no events accumulated for one — which is what the contract asks for, and it was true. What accumulated was the pid. Nothing monitored a subscriber or pruned one, so a supervised consumer that restarts left its old pid behind on every restart.

  That is linear cost on the hot path: deliver/4 walks the whole set and calls Process.alive?/1 per entry, per message. Measured in dp_exchange_core 0.3.3 —

  dead pids in set	µs per fan-out
  0	0.095
  200	4.301
  1000	22.842

  — roughly 240× at a thousand accumulated pids, inside the one process every subscriber's data flows through.

  Subscribers are now monitored, and a :DOWN drops the pid from every set it was in.

  A registered name is deliberately not pruned. A pid that has died is gone permanently, so removing it is always right. A name is not a process: subscribe/2 accepts one precisely so a consumer can restart under it, and a monitor fires when the current holder dies. Pruning on that would silently unsubscribe a consumer whose supervisor is about to bring it straight back under the same name — data loss with nothing to notice it by, which is worse than the leak. A name cannot leak anyway: the set holds one atom however many restarts happen.

[0.4.11] - 2026-09-11

Added

• check_doc_sources.sh now checks whether its own manifest is COMPLETE. Everything it did before verified the sources that were listed; nothing verified that the list covered what this package's docs/reference/ actually cites. A checker whose coverage nobody audits reports "all sources resolve" while saying nothing about the sources it was never told about.

  The gap was real: dp_exchange_gemini cited 22 distinct URLs and listed 12, leaving two genuine vendor documentation pages — the WebSocket streams introduction that websocket-api-replacement.md names as its source, and one of the four API specifications endpoint-inventory.md diffs — unchecked by anything.

  Two classes, reported separately, because only one can be judged mechanically:

  UNLISTED — cited on a host the manifest already names as documentation. Same vendor, same docs site, different page: near-certainly a source that belongs in the manifest.

  UNKNOWN — cited on a host the manifest does not name at all. Deliberately not assumed to be documentation, because most are not: api.gemini.com, api.sandbox.webull.com and api.schwabapi.com are venue APIs, and adding one here would put a live venue into a weekly scheduled fetch. D7 is explicit that a venue seeing a package poll it on a timer will rate-limit or block. These are listed for a person to classify and never auto-added.

  Non-blocking, like the rest of the script: it prints and does not change the exit code. An unlisted page is a gap in evidence, not a broken build.

• All three of this package's scheduled checkers were run by hand for the first time, and they pass. Every one of them had never executed: they are scheduled weekly for Monday and landed on a Tuesday, so no cron had come around. A checker nobody has watched run is a checker nobody has proved works — and running these found the manifest-coverage gap above, which is not the defect any of them was written to catch.

  No vendor drift: every cited documentation source resolves exactly as recorded, and the committed endpoint inventories match the vendors' current indexes.

[0.4.10] - 2026-09-11

Changed

• CI runs mix test --cover --warnings-as-errors. mix compile --warnings-as-errors already covered lib/, but test files are compiled by mix test, which had no such flag — so a compile warning in a test file was permanent and green. Together the two now mean no warning survives anywhere in the build.

  The argument is not tidiness. A handful of permanent warnings is exactly the noise a genuinely wrong one hides behind. The gap was found by running script/check_dependency_floor.sh by hand — a checker scheduled weekly that had never once executed, because it landed on a Tuesday and its cron is Monday — and reading what scrolled past. dp_exchange_core 0.3.2 fixes five such warnings in the shared conformance suite, two of which were real defects that made every venue package noisy.

  Verified by injecting an unused function into a test file and confirming the run aborts: a gate nobody has watched fail is a gate nobody has proved.

• Two dead things in this package's own tests, which were the only compile warnings in the whole family's suites. feed_test.exs carried a copy of dead_pid/0 with no caller — the test that used it moved to feed_terminate_log_test.exs, which has its own copy, and the helper stayed behind. And feed_terminate_log_test.exs's connected_shard/1 had a default argument no call in that file ever used, since every one names its shard explicitly.

  Both are small, and the reason they are worth a changelog line is that they are what the new --warnings-as-errors gate had to clear before it could be turned on at all. Noise is only tolerable until it hides something.

[0.4.9] - 2026-09-11

Changed

• dp_exchange_core floor raised to ~> 0.3.1. Core 0.3.0 deleted Core.DataProvider and Core.FeedBehaviour — two contracts with zero implementers, one of which was a second, competing definition of the venue interface carrying every shape this family has since fixed (prices as strings, providers as strings, balances with no timestamp, a single quote timestamp, {:error, String.t()} flattening the refusal/error distinction). A venue author who found it first would have built all of those, plausibly, and every one would have compiled.

  No code changes here: this package referenced neither module. The floor moves because a pin of ~> 0.2.8 would not resolve 0.3.x — the pin doing its job, not a problem to route around — and because staying behind would leave this package on a Core that still ships the contradicting contract.

  Resolved and compiled against before the pin was written, per the rule this file's own dependency comment already records: a floor is only correct once it has been resolved, never once it has been reasoned about.

[0.4.8] - 2026-09-11

Added

• This package now emits the [:dp_exchange, :link, …] telemetry the contract has documented since it was written. Core.Telemetry said these are the events "every venue package emits"; there was not one :telemetry.execute/3 call anywhere in the family for as long as the spec existed. :telemetry.attach/4 against a name nobody emits succeeds — so a consumer wired a dashboard to it, got no error, and saw an empty panel, which reads as a venue with no traffic rather than as an unimplemented spec.

  :link, :up and :link, :down on the connection transitions, and :link, :event per frame with its wire size. The request and rate-limit events come free with dp_exchange_core 0.2.8, since every venue's REST goes through Core.HttpClient and every metered call through Core.DefaultRateLimiter.

  The metrics channel is alongside the notice channel, never instead of it. A Core.Notice is a condition a consumer must ACT on; telemetry is aggregate and lossy by design. A consumer that alarmed on a telemetry gauge would be acting on a channel documented as droppable, and one that graphed notices would be graphing something it is meant to handle.

  Two details worth stating, because both are places a plausible-looking number would have been wrong:

  A frame is counted whether or not it parses. The question the event answers is "is the venue sending", and a frame this package could not read is still a frame the venue sent — counting only what parsed would make a decoder bug here look like a silent venue.

  There is no :link, :reconnect_attempt from this package. It reconnects immediately and keeps no attempt counter, so the only number it could report is attempt: 1, every time — which renders a reconnect loop as an endless series of first attempts. That is worse than no event. dp_exchange_schwab tracks login_failures and does emit it.

Changed

• dp_exchange_core floor raised to ~> 0.2.8, which is where Core.Telemetry's emitter functions live. A venue calling :telemetry.execute/3 directly would be naming events by hand in five places — five chances to write :link_up instead of [:dp_exchange, :link, :up], with the drift invisible, since a wrong name emits successfully and simply never reaches a handler — and would be using a transitive dependency it never declared.

[0.4.7] - 2026-09-11

Added

• Back-pressure: a slow subscriber no longer gets an unbounded mailbox. Core.Venue's subscribe/2 doc promised this from the day the contract was written, and no venue in this family implemented any of it — every one fanned out with a bare send/2 and had never looked at a subscriber's mailbox. A consumer that stalled accumulated a mailbox until the node died, with no notice, no log line, and coverage/1 reporting perfect health throughout, because the feed genuinely was delivering.

  Past a bound (default 10,000 queued messages, :max_queue_len at start) this feed stops sending to that subscriber and emits a :degraded notice naming it, the queue length and the bound — and a second severity: :info notice when it catches up. The pair brackets exactly the window a consumer has to reconcile from the pull endpoints.

  Implemented in dp_exchange_core 0.2.6 as Core.Fanout, shared rather than written five times. Three properties worth stating, because they are what make dropping acceptable at all: another subscriber that is keeping up is unaffected; coverage/1 does not change, because it reports what the venue delivered to this package and not what this package forwarded; and notices are never subject to the bound, since the notice saying a subscriber is being dropped must not be the first casualty of that same subscriber being dropped.

  See usage-rules.md, "A slow subscriber gets dropped, and told".

Changed

• dp_exchange_core floor raised to ~> 0.2.6, and this one is hard. Feed calls Core.Fanout.max_queue_len!/2 at init/1 and Core.Fanout.deliver/4 on every payload. Against a lower Core this package does not misbehave, it fails to compile — which is the good outcome.

• The pid-or-registered-name subscriber resolution moved to Core.Fanout.resolve/1. All five venues had written it identically since DpCryptoManagement's issue #15; the data path and the notice path now share one definition, so they cannot drift into disagreeing about what counts as a reachable subscriber.

[0.4.6] - 2026-09-10

Fixed

• A link drop flipped the shard's connected? and left coverage/1 answering :stream for what that dead connection had been delivering. Socket.handle_disconnect/2 returns {:reconnect, …}, so the socket process survives a transport drop and no :EXIT ever reaches isolate_crashed_shard/3 — the one path that cleared delivery records. So between a drop and a successful resubscribe, that shard's symbols reported as arriving when they were arriving from nowhere; and where the reconnect restored the socket while the venue silently failed to restore a symbol, it reported :stream indefinitely.

  This package had already written down why that is wrong, on the crash path: "coverage/1/coverage_by_kind/1 must not keep answering :stream for a shard that just crashed … until this, coverage/1 itself kept lying in the meantime." The reason does not depend on what killed the link, so the :link_down clause now drops the same records the same way — scoped to that one shard, since the others are on their own sockets. The shard keeps its entry, unlike the crash path: it is reconnecting rather than dead, and its symbols return as frames arrive after the next resubscribe.

  dp_exchange_core 0.2.5 writes the rule into Core.Venue's coverage/1 doc — observation is scoped to the current transport session — and records why it cannot be carried by a conformance assertion. All four streaming venues in the family had this wrong in the same way and are fixed in the same batch.

[0.4.5] - 2026-09-10

Fixed

• A venue-rejected symbol's 24-hour exclusion was timed on the wall clock, so it could outlive its own bound. state.rejected stored :os.system_time(:millisecond) + ttl and compared against the wall clock again later. That is an in-VM duration — exclude this symbol for 24 hours from now — and the wall clock is not a duration source. An NTP step, a host resync after a bad RTC, or a VM resuming from a snapshot moves it backwards, and every unexpired rejection silently gains exactly that much extra life. The TTL is 24 hours precisely so a "the venue refuses this" belief has a bound; a belief that can outlive its bound by however far the clock jumped is the bound not holding. A forward step is the mirror image — every rejection expires at once and the shard re-subscribes symbols the venue is still refusing.

  Both sites now use System.monotonic_time/1, which is what Core.PollingFeed already computes its own staleness window with. Nothing in the facade changes; a symbol still returns to shard composition on the first reshard after its TTL, and now does so after the TTL it was given.

  Found by sweeping every clock read in the family. This was the only in-VM duration still measured on the wall clock. The auth-token expiries and the request nonces sitting beside it are wall-clock on purpose — those instants come from the venue and are compared against the venue's clock, not ours — and were left alone. The delivering timestamps in this and three sibling feeds are written and never compared, so their clock source decides nothing today; that is noted here rather than changed, since changing it would be motion without a defect behind it.

[0.4.4] - 2026-09-10

Fixed

• Every venue notice arrived with message: nil while the venue's own words sat in details.venue_notice["content"] (dp-exchange-core issue #33). A consumer rendering notice.message printed nothing while this package held the text — 230 times in 66 minutes on the reporter's node, over "Permission grabbed by other session, category : us-crypto", which is not a line to make look like noise.

  :message is now set from the venue's field, with the raw body still in :details. handle_packet(state, {:connack, 105}) already did this; the notice topic path simply never had.

  "content" is an observed key, not a documented one — the vendor publishes that the topic carries JSON and never publishes its field schema, so this is labelled as such at the code. Reading it is safe rather than a guess: absent or non-string yields nil, the raw body is untouched, and nil keeps meaning the venue sent no text — which is the right answer for the code-only shape the same reporter saw alongside it.

  A notice that is not JSON at all used to be dropped silently. That is the same defect one level down, so its text is now carried too — unless the payload is not valid UTF-8, in which case there are no words to keep and forcing them into a log line only produces mojibake that reads like a bug in whatever renders it.

Added

• :resubscribe_interval_ms is a start option, defaulting to the previous hardcoded 60_000 and validated at init/1.

  It exists because of the second half of that issue. The reporter asked whether this package's four shards are taking the us-crypto category from each other, and the rate is suggestive: four connected shards re-asserting once per 60 s is 4/min, against their measured 230 in 66 minutes (3.48/min). Arithmetic agreeing is a hypothesis, not a finding, and nothing here can probe a venue that needs a credential this repository must never hold.

  So what shipped is the knob that lets them settle it: raise it to 300_000 and the notice rate should fall to a fifth if this timer is the trigger, and not move at all if it is not. dp_exchange_coinbase already exposed the identical option — this venue keeping it private is what made a live degradation undiagnosable from outside.

[0.4.3] - 2026-09-10

Documentation

• Rest.wide_timeframes/0's reasoning is now the family's written rule, not a local inference. It explained why a width reachable on any path belongs in a flat historical_timeframes — correctly, and before anything said so. dp_exchange_core 0.2.4 writes that rule into Core.Capabilities and cites this function as its worked example, so the doc here points at it instead of re-deriving it.

  The half worth keeping visible is the second one: a union declaration is only honest because get_historical_prices/5 fails closed — {:error, {:unsupported_timeframe, _}} for a crypto or event-contract category — rather than degrading to the nearest width it does serve.

[0.4.2] - 2026-09-10

Fixed

• No published version was attributable to a changelog entry (dp-exchange-core issue #32). Every entry in this repository's CHANGELOG.md sat under ## [Unreleased] — in the published tarball, since CHANGELOG.md ships inside it — so a consumer could not tell which version introduced a breaking change, or whether they had already taken one.

  That mapping is load-bearing here rather than cosmetic. This family signals a breaking change with a minor bump, and those changes are repeatedly a refusal tuple or struct gaining a field: invisible to the compiler, and invisible to a test that pins the old shape. The reporting consumer's written upgrade procedure is "read CHANGELOG.md for a ### Changed — BREAKING section, then grep for every clause matching the old shape" — which needs version → change. Without it, ### Changed — BREAKING says that the shape changed and never whether they already have it.

  They gave two incidents from the same three days, and the difference between them is the whole argument: dp_exchange_gemini 0.1.42's refusal-shape change was found after shipping, by reading a fix comment, while dp_exchange_webull 0.4.0's was caught before — because that entry happened to name the version in its prose.

  Two halves, because fixing only one would have let it recur immediately:

  • Going forward, the release pipeline cuts a ## [x.y.z] - YYYY-MM-DD heading itself, in the publish job and before mix hex.publish — a heading added after the upload would describe a tarball nobody can read.
  • Retroactively, the accumulated block now sits under a ## [<version>] and earlier heading. Attributing each of ~1,600 lines to the exact release that carried it is archaeology; this restores the one fact a consumer needs from it — that none of it is pending — which is what the reporter suggested.

  The issue measured five packages, from their deps/. dp_exchange_schwab has the same defect and is not one of their dependencies, so it could not appear in their table: six instances, all fixed here.

[0.4.1] and earlier - 2026-09-10

Everything below this line is published. Entries were accumulated under [Unreleased] from the first release to 0.4.1, so no reader could tell shipped work from pending — dp-exchange-core issue #32. Attributing each entry to the exact version that carried it would be archaeology across hundreds of releases; this heading restores the one fact a consumer actually needs from it, which is that none of it is pending.

Releases from here on cut their own ## [x.y.z] heading at publish time, so this is the last block that will ever need a range.

Changed — BREAKING

• A refusal now carries the venue's HTTP status as well as its words. {:refused, {:venue_error, 401, "signature mismatch"}}, where it used to be {:refused, {:venue_error, "signature mismatch"}}.

  This package refuses on 400, 401 and 403, and all three arrived at a caller looking identical — while their remedies are opposite: a 400 means fix the request, a 401 means refresh the token and call again, a 403 means a person must change what the credential is entitled to. The clause raising the refusal even documents the 401 remedy in a comment, so the code knew which status it had matched and then discarded the only thing that could tell a caller which one it was.

  An unrecognised body keeps its status too — {:venue_error, 403} rather than a bare :refused. Thin, but it is the difference between "the venue rejected this and here is which kind" and "something went wrong". oauth_token/3 was worse still: it returned the raw body as the reason, with no classification at all, on a call where 400 (bad grant) and 401 (bad client credentials) again mean different things.

  This venue was the outlier. dp_exchange_coinbase, dp_exchange_robinhood and dp_exchange_schwab all already used {:venue_error, status, detail}. Found by sweeping the family for the principle a consumer named on dp-exchange-gemini#1 — a known reason is never less informative than an unknown one — generalised to: a caller must never be handed less than this package already had.

  If you pattern-match refusal reasons, check that clause before upgrading. A caller matching {:venue_error, message} now falls through to whatever catch-all follows it, silently, with nothing raising. That exact trap cost a consumer a canonical error mapping on dp_exchange_gemini, which is why it is called out here rather than left to be found.

Documentation

• usage-rules.md now answers the question a consumer actually has after 0.2.0: when is venue_time nil here? The migration note said what the fields mean; it did not say what this venue does with them, which is the part a caller writes a branch for.

  Never, on this venue: every Quote and OrderBook parses a time the venue sent and fails closed when it cannot, so a nil branch here is dead code.

Changed — BREAKING

• Core.Types.Quote and Core.Types.OrderBook no longer carry :timestamp. They carry :venue_time (the venue's own, nil where the venue publishes none) and :observed_at (when this package read it, always present). Requires dp_exchange_core ~> 0.2.1; this package's own version takes a minor bump to signal it.

  :timestamp was documented as the venue's own and "never invented", and two packages in this family could not keep that promise, because the frames they decode carry no venue time at all. With one field their only options were to lie or drop real data, and they lied.

  This venue always had a venue time to give, on every Quote and OrderBook it builds, so :venue_time carries exactly what :timestamp did and :observed_at is new information rather than a replacement.

  The full reasoning, the three options weighed and the consumer's own argument for this one are in dp_exchange_core's docs/design/closed/2026-09-09_venue-time-and-observed-time.md, announced and answered as dp-exchange-core issue #31. Trade, Fill, Balance and OrderBookDelta are unchanged.

Added

• script/check_endpoint_inventory.sh and docs/reference/webull/endpoint-pages.txt — a weekly, non-blocking diff of the vendor's published endpoint reference pages against a committed capture, via .github/workflows/inventory-check.yml. One HTTP request: this vendor publishes no machine-readable specification, but its sitemap.xml lists one docs/reference/* page per endpoint, so that set is the closest thing to an operation list available here.

  This venue is why the mechanism exists. The identical sitemap search found developer.webull.com/apis/docs/rate-limits/ — a per-endpoint rate-limit table that had been published since 2026-08-14 while this package declared a REST ceiling five times too permissive, against a venue whose documented penalty for exceeding it is a temporary IP block. Nobody found it for weeks because nobody was comparing indexes. A page appearing here now says so.

  Baseline: 248 reference pages, captured 2026-09-09, unchanged on the check's first run.

Fixed

• Reads now carry @call_timeout explicitly, exactly as writes already did. coverage/1, coverage_by_kind/1, status/1 and wanted/1 took GenServer.call/2's implicit five seconds while every write named a generous one, and that asymmetry is what turned a bounded delay into a dead caller in dp-exchange-core issue #28: coverage/1 is the call a consumer's health check makes, so any moment the Feed was legitimately busy for longer than five seconds turned a health check into an exit — and into a dead consumer process, when the read happened inside the consumer's own handle_call/3. The blocking is fixed at its sources rather than papered over here; this is the second line of defence. A read that has to queue behind something should wait for it, not die of it.

Fixed

• INVALID_SESSION was retried as a subscribe failure forever — dp-exchange-core issue #30. All four MQTT shards stopped delivering and the blind resubscribe timer kept firing against sessions the venue had already discarded: 1,479 identical warnings over fourteen hours, 260 of 325 symbols receiving nothing, and a manual Feed restart as the only recovery. INVALID_SESSION says the session a subscribe is addressed to no longer exists, so re-sending that same subscribe is the one action guaranteed not to help — and nothing escalated from "subscribe failed" to "reconnect", so it could not recover in-process.

  Two causes, both fixed. Subscription collapsed the venue's answer into the opaque {:exchange_error, :webull, "HTTP 417: ..."} string, which Feed could log and could not match on; a 417 carrying INVALID_SESSION is now {:error, {:invalid_session, session_id}}, with the dead session id parsed out of the venue's prose ("...not exist for session:<id>") because on a sharded venue three of four sessions may be perfectly fine. A message this parser cannot read still returns :invalid_session with a nil id — the recovery does not depend on the id, and refusing to name the failure over a missing detail would restore the fourteen-hour loop.

  Feed now rebuilds the shard rather than retrying it, through the recovery it already had for a crashed socket: drop the shard and reopen it, which mints a fresh session id in open_socket/2. It has to be a reopen and not a retry, because the session id is minted when the socket opens — there is no subscribe-level fix available at all. Handled in the shared handle_subscribe_result/3 funnel, so every subscribe path recovers the same way; the blind resubscribe is merely where it was first observed.

  Two details that would be easy to get wrong, both recorded at the code: the shard leaves state.shards before its socket is stopped, so the resulting {:EXIT, ...} finds no shard and cannot drive a second concurrent rebuild through isolate_crashed_shard/3; and the socket is stopped, not abandoned, because unlike a crash the process is very likely still alive holding a connection the venue has already discarded — this venue allows five concurrent connections per App Key, so leaking one per stale session would turn a recoverable outage into an unrecoverable one.

  It is reported as a :link_down notice naming INVALID_SESSION, rather than latched as a generic resubscribe failure. The reporting consumer's point stands on its own: the only signal before this was a WARN line saying the symbols were stuck, offering no path out. This is the third failure mode of the resubscribe path — #17 added it (symbols going quiet on a live session), #23 fixed it failing throttled, and this is the session underneath it being gone.

  A note on why it stayed invisible for fourteen hours, worth carrying: the failure is partial by construction. Dead sessions strand their symbols while surviving ones keep delivering, so venue-wide "has this gone quiet" answered no the entire time — the reported min stream age was 81s while the p50 was 3,497s.

Documentation

• Credentials' moduledoc now says that the redaction wrap lives in child_spec/1, and that bypassing child_spec/1 bypasses it. Requested by the consumer who verified the dp-exchange-core #29 fix and then went looking for their canary in their own supervisor's state — and found it. Their supervision code builds the child spec itself (start: {__MODULE__, :start_feed, [module, opts, pairs]}) for a legitimate reason: a Core.PollingFeed-shaped facade defaults subscriber to self(), which resolves to the supervisor when start_link/1 is called from init/1, so a different delivery target can only be set at start_link time. On that path child_spec/1 never runs, their supervisor stores the raw map, and OTP renders the live key on the next crash exactly as before. Upgrading does not fix it, because nothing from this package is on that path.

  No code change: wrap/1 and wrap_opt/1 were already public, which was all that path needed. What was missing was anyone saying so — the natural assumption, "upgraded, therefore redacted", is wrong there, and assertion 22 cannot see it because it asks about child_spec/1's own rendering. dp_exchange_core's usage-rules/auth.md carries the full version, including the reshaping case that bit them: a host mapping its own key names into a venue's and returning a bare map re-introduces the leak in its own code, downstream of anything a package can reach.

Fixed

• Credentials were written to the log in cleartext by any crash — dp-exchange-core issue #29. A supervisor stores the {module, :start_link, [opts]} MFA its child spec names, and OTP writes that argument list through inspect/1 into the Start Call: line of the report it logs on any child termination. :credentials arrived as a plain map, so every crash printed the live secret in full. It needs no unusual conditions, it lands in ordinary application logs — the artifact most likely to be shipped to an aggregator or attached to a bug report — and it defeats credential hygiene upstream of it: a consumer can hold the key encrypted at rest and still have it written out in the clear. The reporting consumer found live keys this way and nearly pasted them into a GitHub issue while reporting a different bug.

  child_spec/1 now wraps :credentials with DpExchange.Webull.Credentials.wrap_opt/1, and the placement is the fix: wrapping in start_link/1 or init/1 does nothing, because by then the supervisor above has already captured the raw list. Redacting the value rather than setting the :sensitive process flag is deliberate — that flag suppresses the whole report, including the stack trace that made the unrelated bug diagnosable. This keeps the report and removes only the secret. dp_exchange_core's conformance suite gains assertion 22 for exactly this, so it cannot come back here or arrive in a new venue.

Fixed

• The REST ceiling was five times too permissive, and the entry below it in this same unreleased section is what made it so. public_ceiling/authenticated_ceiling are now %{limit: 60, per_ms: 60_000} — 60 requests per 60-second window, the venue's own units — replacing the %{limit: 5, per_ms: 1_000} the next entry describes arriving at. That 5 came from Webull's Market Data FAQ ("a rate limit of 300 requests per 60 seconds"). The FAQ is real and still says that. It is also contradicted by the venue's own per-endpoint rate-limit table, developer.webull.com/apis/docs/rate-limits/, which caps every market-data endpoint — crypto, stock, option, future, event contract, display and non-display, including the HTTP streaming/subscribe calls — at 60/60s in production and 30/60s in sandbox. A second, independently maintained set of pages corroborates it in different units: each endpoint's own reference page states "1 request per second per App Key", which is 60/60s.

  The venue contradicts itself, so this was decided by rule, not preference: the per-endpoint table is more specific, newer, states its own units, is corroborated, and is the stricter of the two. Fail closed. The asymmetry matters more than usual here — that page also states that repeatedly exceeding a limit "may result in temporary IP-level blocking", so guessing high does not cost latency, it costs the connection.

  This number has now been wrong twice in a row, in the same direction, and the second time it carried a citation. That is the part worth keeping: a citation makes a number checkable, it does not make it right. Operationally the tightening costs nothing — Subscription.subscribe/3 batches symbols into one call per shard rather than one per symbol, and get_price/3/get_top_of_book/3 are per-symbol calls a consumer paces itself.

• UAT was metered against production's budget. Supervisor's limits/1 (was limits/0, now taking opts) halves the declared ceiling to 30/60s when Environment.resolve/1 says :uat, which is the venue's own relationship between its two columns rather than a margin invented here. The Supervisor already gave production and UAT separately named limiters precisely so one could not spend the other's budget; handing both the same limits left that separation cosmetic in the direction that bites — UAT pacing itself against an allowance the sandbox refuses, surfacing as a 429 on a test run with nothing pointing at the cause. capabilities/0 still declares the production figure and can declare nothing else: it takes no arguments. limits/1 is now public and documented, matching its already-public siblings limiter_name/1 and feed_name/1, so the derivation is checkable; test/dp_exchange/webull/rate_ceiling_test.exs pins both environments and the burst that follows each.

• A cited vendor page 404s, and that is how all of the above was found. docs/reference/webull/rest-rate-limits.md cited .../docs/reference/option-market-data/; the page is options-market-data, plural. Three bullets in that file carried per-endpoint figures — "40 requests per 2 seconds" for orders, "600 requests per minute" for futures, "60 requests per minute" for option tick data — each attributed to a reference page. Every reference page on this vendor's site was fetched and searched: none of them contains any rate-limit text of that form. Those bullets are deleted rather than corrected — unsourced numbers wearing a citation are worse than missing ones. The real per-endpoint figures, from the table that does publish them, are now recorded in full.

• public_ceiling/authenticated_ceiling were %{limit: 10, per_ms: 1_000} with no comment and no mention anywhere in capabilities/0's own measured_against string — unlabelled and inherited, and load-bearing: Supervisor's private limits/0 feeds this straight into the real DefaultRateLimiter this package starts, so the unexamined number was actually throttling (or failing to throttle) every REST call. Found by a family-wide sweep for the @pairs_per_socket/@shard_spacing_ms defect class in dp_exchange_coinbase — an unverified number sitting where a cited one belongs. Webull's own Data API FAQ (developer.webull.com/apis/docs/market-data-api/faq/, read 2026-09-08) states "a rate limit of 300 requests per 60 seconds" — 300 / 60 = 5 — now docs/reference/webull/rest-rate-limits.md. Both ceilings are now 5, not 10; every endpoint here is signed (credential_benefit: :required), so there is no separate public/authenticated figure to distinguish. This lowers the rate this package will request against the venue — a caller running close to the old, unverified 10 may now see requests queue that previously went straight through — but the old number rested on nothing, and this one rests on the venue's own stated ceiling. Two smaller citation gaps found in the same sweep, values unchanged: Rest.place_orders/3's 50-orders-equities-only batch limit now cites docs/reference/webull/batch-orders.md (previously "its page says so" with no committed source); Rest.get_order_book/3's depth default of 10 is now labelled as generalised from the event-contracts endpoint's documented default rather than confirmed for the stock/futures endpoints it actually applies to — the stock endpoint's own parameter table has never been captured (JS-rendered, same limitation negative-claims.md already records elsewhere), and the futures endpoint's own page states depth is 1–10, required with no default, making the prior "L2 defaults to 10" doc comment an overgeneralisation for that case.

• A malformed WebSocket close frame from Webull crashed a shard's socket before handle_disconnect/2 ever ran — dp-exchange-core issue #27. Webull sometimes closes this venue's MQTT-over-WebSocket connection with a close frame carrying prose where RFC 6455 §5.5.1 requires a 2-byte status code — measured live: <<136, 10, 98, 121, 101, 45, 98, 121, 101, 33, 33, 33>>, i.e. "bye-bye!!!". The first two bytes parse as "by" = 25209, outside every valid close-code range (1000–1015, 3000–4999). WebSockex.Frame.parse_frame/1 correctly returns {:error, %WebSockex.FrameError{reason: :invalid_close_code}} for this; websocket_loop/3 one level up matched only {:ok, frame, buffer} and :incomplete} even though parse_frame/1's own @spec names the error tuple as a real return value, so the process raised an uncaught CaseClauseError and died before any callback ran — Socket.handle_disconnect/2 never fired. Measured consumer impact: 117 crashes in 7 minutes across three shards, roughly one close every 10 seconds per shard, sustained. Feed's own supervision reopened each shard, so nothing alarmed; the venue simply never reached full coverage (one consumer's fresh-tick count oscillated between 76 and 243 against a 325-symbol scope, all day).

  websockex 0.5.1 is the latest Hex release and still has this; confirmed the same unguarded case is still present, unreleased, on dominicletz/websockex's current master (2026-09-08) — the maintained upstream repo (Azolo/websockex is abandoned). There is no upstream fix to wait for.

  Fixed by vendoring, not by switching transport. A transport swap (Mint.WebSocket, :gun, fresh) was evaluated and rejected: this package already owns its transport by design (CLAUDE.md: "Core ships no venue-specific dependency… a venue that speaks WebSocket ships what it needs to speak it"), but websockex already supplies TCP/TLS connection handling, the HTTP upgrade handshake, frame fragmentation reassembly and automatic reconnect — replacing all of that to work around a two-line defect would have meant hand-rebuilding a WebSocket client on a production incident's timeline, a strictly larger and riskier change for the same outcome. Intercepting the buffer before WebSockex.Frame.parse_frame/1 sees it was considered and ruled out on inspection, not assumption: every byte from the socket reaches websockex's own private process loop directly (WebSockex.Conn. controlling_process/2 + set_active/2), with no seam in the callback model for a consumer to sit in front of it.

  A git-dependency fork was rejected because Hex refuses to publish a package that depends on git — shipping a fork this way would mean publishing an entire separate package under a new name on Hex, a maintenance commitment (a new repo, its own CI, its own releases, tracking every future upstream websockex release for anything beyond this one fix) out of proportion to a two-line defect, and one this package's own authority does not extend to unilaterally taking on.

  Instead, lib/vendor/websockex.ex vendors websockex 0.5.1's single process-loop file (not the whole package — WebSockex.Frame, WebSockex.Conn, WebSockex.Utils (hidden from its own docs, so plain text here), WebSockex.Application and every WebSockex.*Error struct stay the real, unmodified dependency; none of those carried the bug), private to this package, under DpExchange.Webull.Vendor.WebSockex — never bare WebSockex, so a consumer who also depends on the real websockex package (directly, or through another venue in this family) is unaffected. Exactly two things changed from upstream, both marked ## VENDORED FIX at their call site: (1) websocket_loop/3 gains a clause for {:error, %WebSockex.FrameError{}}, routed through the already-existing handle_close({:error, reason}, ...) path sync_send/5 already used for a send-time framing error — RFC 6455 §7.1.7's specified response to a peer's malformed frame is to close the connection, not crash reading it, and that path already sends this side's own close frame and runs the ordinary disconnect flow, so no new recovery logic was written; (2) WebSockex.Utils.spawn/5 (hidden from its own docs, so plain text here) hardcodes the literal atom WebSockex as its :proc_lib entry module, which would have booted every vendored socket into the real, unpatched module regardless of the rename — do_spawn/2 is reimplemented locally using __MODULE__ to close that one gap. See the vendored module's own moduledoc for the full incident, and an upstream PR was opened against dominicletz/websockex alongside this fix (it cannot be the fix that ships today, but it is worth landing regardless).

  mix.exs now pins {:websockex, "== 0.5.1"} exactly rather than ~> 0.5.1: the vendored file calls WebSockex.Conn's and WebSockex.Frame's functions the same private-in-spirit way the original did, an internal API those modules never promised to keep stable across releases the way their own public behaviour is — a ~> floor would invite the exact failure this same dependency already caused this family once (the send_frame/3 arity floor, this file's own earlier entry). lib/vendor/ sits outside test/dp_exchange/webull_contract_test.exs's (narrowed) package_root, .credo.exs's scanned paths and mix.exs's coverage ignore_modules — all for the same reason: this is third-party code carried for a two-line necessity, not code written to this family's own conventions, and none of those checks can see the OTP dynamic dispatch (:proc_lib, :sys) that keeps several of its exports legitimately public with no caller :xref can find.

  Proven by test/dp_exchange/webull/socket_malformed_close_test.exs: a real Socket.start_link/1 against a real local TCP server that completes the WebSocket handshake and then sends the exact 12-byte frame from the incident. Confirmed to fail with the pre-fix CaseClauseError when the fix's one clause is removed, and to pass with it restored — handle_disconnect/2 runs (:link_down notice received, naming the WebSockex.FrameError and :invalid_close_code reason), and the socket process is still alive afterward rather than crashed.

• Why the venue closes the connection at all — investigated, not fully resolved. Fixing the crash turns each of these into a clean reconnect instead of a crash, but does not by itself explain why Webull sends this close so often. Ruled out with evidence already in hand before this fix: the 60s keep-alive/30s PINGREQ schedule cannot explain a ~10s close cadence, and shards do not share an MQTT client id (each socket, and each reopen, gets its own generate_session_id()), so the venue's documented "a new connection with the same session_id kicks the previous one" rule does not apply at the shard level. The consumer's own hypothesis — a crashed socket never sent a clean MQTT DISCONNECT, so the broker held the dead session for its documented ~1 minute retention window while shards kept reopening, and enough overlapping zombie sessions eventually hit the "5 concurrent connections per App Key" ceiling (Webull's own docs: exceeding it returns error code 105, and duplicate/expired sessions get kicked with no more specific reason given at the WebSocket layer) — is plausible, evidence-consistent, and testable, but not established: this repo holds no Webull credential and cannot run it live. This fix is the fix that makes the hypothesis testable at all, since before it no shard ever sent a clean DISCONNECT in the first place.

  The exact probe, for a consumer running this live (as the reporting consumer has offered to): after upgrading, watch a shard's :link_down notices across an extended run. If the ~10-second-per-shard close cadence stops or drops substantially, the zombie-session hypothesis is confirmed. If it persists at the same rate with clean reconnects now happening every time, the hypothesis is falsified and the cause is something else — a concurrent-connection cap behaving differently than documented, an idle-connection policy independent of MQTT keep-alive, or something the CONNECT packet itself triggers — and would need a second, separate investigation with the close reason now visible on every occurrence (this fix logs WebSockex.FrameError's full detail on the malformed case; an unrelated future close would carry its own, different reason, distinguishable in the same :link_down notice).

• dp_exchange_core was pinned to ~> 0.1.48, a floor this package has not actually run against since capabilities/0 started declaring no_venue_contact: [{:get_fees, 2}]. Capabilities.new/1 builds the struct with struct!/2, and no_venue_contact is a key Core only defines from 0.1.68 — any lower resolution raises KeyError the first time capabilities/0 is called, which is every conformance run and every host that calls it during venue discovery. ~> 0.1.48 compiled and every test passed because CI always resolves the newest allowed version (0.1.68, per mix.lock); a consumer whose own dependency graph forced an older Core would not resolve that. Found in a family-wide audit of declared-vs-actual dependency floors, prompted by the same defect class already fixed in websockex (~> 0.4 → ~> 0.5, next entry below — which itself needed a second correction the same day; see that entry). Raised to ~> 0.1.68. This also covers Timeframe.nameable/0 admitting 1y, needed since Core 0.1.57 (see the "capabilities/0 withheld 1y" entry below) — 0.1.68 is the binding constraint of the two. A new test in webull_test.exs asserts the resolved Core's Capabilities struct defines :no_venue_contact, so a future loosening of this pin without a matching code change fails loudly instead of only failing for a consumer.

• websockex was corrected twice in one day, and the first correction was itself wrong. Socket.disconnect/2 calls WebSockex.send_frame/3; mix.exs declared ~> 0.4, which does not have that arity at all. The first fix (0646201, this package's own commit, undocumented here at the time — a gap this entry also closes) raised the floor to ~> 0.5, reasoning that the third send_frame argument "only exists from 0.5". It does not: send_frame/3 is new in 0.5.1, and ~> 0.5 still permits 0.5.0, which lacks it — confirmed by reading both resolved sources directly (deps/websockex/lib/websockex.ex defines only send_frame/2 at 0.5.0; the same file defines send_frame(client, frame, timeout \\ 5_000) at 0.5.1). Caught by script/check_dependency_floor.sh, added the same day family-wide to close exactly this blind spot, on its first real run against this package: resolving ~> 0.5 to its actual floor reproduced the original WebSockex.send_frame/3 is undefined or private warning against 0.5.0 itself. Raised to ~> 0.5.1. No mix.lock change was needed — this package already had 0.5.1 locked; only the stated floor, and the comment reasoning about it instead of resolving it, were wrong. See docs/design/closed/2026-09-08_dependency-floor-check.md in dp_exchange_core for the full family-wide writeup.

• This reverts and corrects get_fees/2's credential gate, added in the "Fix Fake credential gate (Core 0.1.57 assertion 17)" entry below. That earlier entry was wrong about this one endpoint. get_fees/2 builds no request — it answers a crypto spread rate captured from Webull's own published pricing (source: :published_rate) — and yet, since that sweep, both Rest.get_fees/2 and Fake.get_fees/2 refused with {:error, {:missing_credentials, :webull}} when called without one. The sweep's reasoning was that the real path "had never run through Auth.headers/2", which was true and was exactly the point: there is nothing here to sign. The fake should have been matched to the real path's ungated behaviour; instead the real path was gated to match the fake's incorrect refusal.

  Reported by a consumer (DpCryptoManagement) who resolves venue fees to score candidate strategy genomes before any account is attached — no credential exists at that point by design. With get_fees/2 unanswerable without one, their round_trip_bps computation lost its input and their fee-overcome admission gate, a live-trading gate, could not run.

  Now get_fees/2 answers unconditionally on both Rest and Fake, matching its pre-sweep behaviour. credentials is accepted for shape parity with every other callback and never inspected. A swept audit of the other twelve callbacks the same commit gated (get_accounts/2, get_balances/2, get_positions/1, get_transfers/2, get_transactions/2, quantization/2, place_order/3, place_orders/3, preview_order/3, replace_order/4, cancel_order/3, get_order/3, get_orders/2) and the twelve gated by "Gate the widened Fake surface on credentials" (get_option_chain/2, get_option_expirations/2, list_watchlists/1, get_watchlist/2, create_watchlist/3, update_watchlist/2, delete_watchlist/2, get_financials/3, get_corporate_events/1, get_filings/2, get_news/1, get_screener/2) confirmed every one of them reaches the venue through Rest's signed get/4 or post/4 request path — the gate on all twenty-four is correct and stays.

  Regression test added asserting get_fees/2 answers {:ok, _} with no credential on both Rest and Fake, so this cannot be re-broken by the next credential-gate sweep.

  Moved to dp_exchange_core 0.1.68, which resolves this the way the false positive is actually fixed rather than papered over: assertion 17 gains Capabilities.no_venue_contact, a per-endpoint declaration a venue makes when a specific active endpoint's real implementation never builds a request to the venue. capabilities/0 now declares no_venue_contact: [{:get_fees, 2}].

• market_status/1 answered {:ok, :open} unconditionally — true only for the one asset class this venue does not restrict to trading hours, and a lie for the other four. This venue is not crypto-only: asset_classes/0 is [:crypto, :equity, :option, :future, :event_contract], and equities, options, futures and event contracts all trade on real, exchange-set hours. A consumer checking market status before placing an equity or options order was told the market was open at 3am on a Sunday. Found by dp_exchange_core 0.1.66's widened assertion 17 (the credential gate): this venue declares credential_benefit: :required, and the literal answered {:ok, _} with no credential because nothing here ever read one.

  Now {:error, :not_supported}, declared :unsupported in capabilities/0. Checked against the vendor's own documentation before deciding, per this package's own rule (fail closed; never substitute) rather than assumed: Webull's OpenAPI documents 85 endpoints (docs/reference/webull/endpoint-inventory.md) and none of them is a market-status or trading-calendar call. The one trading-calendar endpoint Webull publishes anywhere, GET /broker/master-data/trading-calendars/list, belongs to a different product entirely — the Broker API, served from broker-api.webull.com rather than this package's api.webull.com, reachable only with its own broker-tier credential obtained through a separate business relationship this package has none of. Even setting the credential question aside, market_status/1 carries no symbol or asset-class argument — it answers ONE status for the whole venue, and this venue spans five asset classes with different calendars, so no single value could ever honestly describe it, reachable endpoint or not. Full reasoning in docs/reference/webull/negative-claims.md and DpExchange.Webull.market_status/1's own doc.

  Breaking for any consumer routing on market_status/1. A caller that previously got {:ok, :open} now gets {:error, :not_supported} and must treat this venue as not answerable for market status, the same way it already must for test_connection/2 and get_rate_limit_status/2.

  Regression tests added in webull_test.exs (describe "market_status/1"); the existing capabilities().endpoints[{name, arity}] == :unsupported sweep in webull_test.exs's "the declaration" tests now covers it automatically. fake_test.exs and fake_injection_test.exs updated: market_status/1 no longer has a real success path, so it is removed from FakeInjection's whole-call injection surface, the same way test_connection/2 and get_rate_limit_status/2 already are.

• Fake.get_corporate_events/1 and Fake.get_news/1 checked credentials before the argument Rest's own equivalents require first, the reverse of Rest.get_corporate_events/2 and Rest.get_news/2's own order (both run required_symbol/1/required_symbols/1 before anything reaches Auth.headers/2). Calling either with neither the argument nor credentials answered {:error, {:missing_credentials, :webull}} here and :symbol_required/:symbols_required for real — a narrow but real way this fake was differently capable than the venue it stands in for. Found by a cross-package audit. Both now check the argument first, matching Rest's order exactly.

• A crash of Feed printed the app_secret HMAC-SHA1 signing key — and, if present, the account's access_token — in cleartext, in OTP's own crash report. Feed keeps state.resubscribe_opts for its entire lifetime so a reconnect or a rebalance can replay a shard's subscription, and that keyword list's :credentials entry was a bare map. replayable/2 also let a fresh :credentials from a later subscribe/2 or update_symbols/2 call overwrite it — unwrapped — on every call that supplied one. OTP's default crash report prints a GenServer's state in full on termination, so a crash of Feed logged the signing key in cleartext — verified by crashing an equivalent process holding %{app_key: "...", app_secret: "...", access_token: "..."} as a bare field and reading the resulting log line back. Process.flag(:sensitive, true) was tried as an alternative and does not help: the same crash, with the flag set, printed the same cleartext state.

  Now Feed wraps the triple in DpExchange.Webull.Credentials, a struct whose Inspect is derived with except: naming all three fields, at both entry points (init/1 and replayable/2) — replayable/2's wrap is conditional on the key actually being present in the caller's own opts, because an unconditional default would have inserted credentials: nil and let Keyword.merge/2 silently discard the already-wrapped credentials sitting in state.resubscribe_opts on every call that did not itself supply fresh ones. Nothing downstream changes: a struct is a map, so Auth.headers/2's %{app_key: k, app_secret: s} = credentials still binds the real values inside the one function that has to sign with them, and app_key_from/1's %{app_key: app_key} when is_binary(app_key) -> app_key still extracts it for Socket.start_link/1. Re-verified against a real crash of the new shape: the log line now reads credentials: #DpExchange.Webull.Credentials<...>.

  Socket's own state.app_key is deliberately left as a bare string — app_key is sent as a plaintext header (x-app-key) on every signed request this venue accepts, so it carries none of the confidentiality app_secret/access_token do, and wrapping it would add a call-site change for no reduction in what a crash of Socket actually exposes.

• coverage/1/coverage_by_kind/1 kept reporting :stream for a shard's symbols after that shard's socket crashed. isolate_crashed_shard/3 (added for the W2 fix, see below) already rebuilt state.shards and fanned out a :link_down notice on a shard crash, but never touched state.delivering/state.delivering_by_kind — the same gap the WS-level :link_down handler has (it only flips connected?: false). A symbol whose only shard had just crashed kept reading as delivering until something else happened to overwrite its entry. Found by a 2026-09-07 supervision audit that asked directly whether coverage/1 tells the truth immediately after a crash. Now cleared in isolate_crashed_shard/3 the same way unsubscribe/2 already clears a departing symbol's delivery record — a symbol whose only shard just died has exactly as little arriving for it as one that was never subscribed.

• FeedTest's terminate/2 describe block asserted on ExUnit.CaptureLog content under async: true, and lost the race on seed 42. capture_log/1,2's isolation depends on a global swap of the Logger backend's output device; a content assertion raced against it is exactly the case concurrency breaks, and this file has 60+ other tests logging at :debug alongside unrelated HTTP request logging elsewhere in the suite under max_cases: 20. refute log =~ "skipped" failed against a blob of another test's log output that happened to contain it. Split into FeedTerminateLogTest, async: false, which removes the race structurally rather than narrowing the substring or widening a timeout — the underlying mechanism genuinely is not concurrency-safe for content assertions. Found by a cross-package audit running the full suite on multiple explicit seeds, which this family's CI does not do by default.

• child_spec/1 did not declare type: :supervisor, so OTP defaulted it to :worker — which also defaults :shutdown to 5_000ms instead of :infinity. A consumer terminating this child gave the whole nested tree (shards, MQTT sessions, rate limiter) only five seconds to shut down gracefully before :kill, rather than letting it unwind on its own terms. Invisible to any single-package review, and found only by diffing child_spec/1 across all five venue packages against each other; dp_exchange_schwab was the only one that already declared it.

• capabilities/0 withheld 1y, a width this venue serves, three Core releases after the reason stopped applying. historical_timeframes was Rest.wide_timeframes() -- @core_unnameable_widths, where the subtracted list was ~w(1y). That workaround was correct when written: dp_exchange_core 0.1.48's Timeframe.nameable/0 had no entry for 1y, so Capabilities.new/1 raised on it, and the package chose to report the gap upstream rather than invent a boundary rule or substitute a neighbouring width. Core 0.1.57's @unbucketable is ~w(1w 1M 1y); the gap closed and the subtraction did not. The declaration is now Rest.wide_timeframes() directly, so it tracks what Rest actually serves instead of a hand-maintained list, and a test asserts the two are equal rather than asserting a literal.

  Worth stating because it will recur: nothing failed while this was stale. The workaround was documented, dated, tested and correct on the day it was written, and its own comment said to remove it "the day nameable/0 adds 1y" — a condition no test could check, in a package whose tests all passed. Found only by a cross-package audit reading each venue's declaration against the Core version it now depends on.

• authenticated_streamable was [] on a venue where every call is signed. It reads as "none of the streamed kinds needs a credential", on a package that declares credential_benefit: :required, builds its MQTT token from Auth.headers/2 in Subscription, and whose broker answers CONNACK 103/104 to anything unsigned. A host asking whether it needed a credential to stream quotes, top-of-book or trades was told no. Now [:quotes, :top_of_book, :trades] — the whole of streamable, since there is no anonymous path to any of them.

  Note the direction, which is easy to get backwards and which usage-rules/feeds.md currently states the wrong way round: Capabilities.new/1 enforces authenticated_streamable as a subset of streamable — "of the kinds you stream, which need a credential" — and raises with "a kind that needs credentials must first be a kind the venue streams". Found by a cross-package audit; dp_exchange_robinhood carried the identical [] for the identical reason.

• FeedTest's W3 control-plane test raced under load and failed intermittently on certain random seeds. assert_receive {:blocked, blocked_pid} waited only the suite's default timeout for a message a blocking test plug sends essentially synchronously once its process is scheduled — normally near-instant, but too tight once this file ran alongside its siblings under async: true with max_cases: 20. Widened to 3,000ms locally; the assertion still returns as soon as the message arrives, so this costs nothing on the passing path. Found by a cross-package audit running the full suite on multiple explicit seeds, which this family's CI does not do by default.

Added

• script/check_doc_sources.sh and docs/reference/webull/doc-sources.tsv — a weekly, non-blocking check that every vendor documentation page this package cites still resolves the way it did when a person read it. It records status and redirect destination, and does not follow redirects or diff content: a permanent redirect is itself the change notice (this family lost a streaming API to one), while content diffing a rendered docs site would be red every week for reasons that are never the reason we care about. This is the instrument that found the 404 above, on its first run. Scheduled Mondays 09:20 UTC via .github/workflows/doc-sources-check.yml, never on push, never in the publish chain, and it touches documentation sites only — never a venue API, which tier-2's never-on-a-schedule rule still forbids.

Changed

• docs/reference/webull/rest-rate-limits.md rewritten against the per-endpoint table, and now records exactly what is and is not machine-readable on this vendor's site. Endpoint descriptions and their rate-limit blocks live in <meta> content and are fetchable anonymously; per-endpoint parameter tables are not, and still require an authenticated console — so get_order_book/3's depth default remains uncaptured, as negative-claims.md already records. The belief that the rate-limit data was likewise unreachable was wrong, and it was wrong partly for a mundane reason now written down: every docs/ URL without a trailing slash answers 301, and the 189-byte redirect stub that comes back reads exactly like a JS-rendered shell unless you check the status code.

Documentation

• Fake's own moduledoc still described a {:refused, :missing_credentials} path under authenticated/1 after that path was changed to {:error, {:missing_credentials, :webull}} — the code was already correct, only the prose describing it had drifted. Found by a cross-package audit comparing this family's credential-refusal vocabulary against each other.

Fixed

• BREAKING: twelve more Fake callbacks on the widened surface still succeeded with no credentials — the same defect as the entry below, on the endpoints assertion 17 structurally cannot reach. get_option_chain/2, get_option_expirations/2, list_watchlists/1, get_watchlist/2, create_watchlist/3, update_watchlist/2, delete_watchlist/2, get_financials/3, get_corporate_events/1, get_filings/2, get_news/1 and get_screener/2 all bound their options as _opts and never inspected credentials, while every one of their real counterparts reaches the venue through Rest's signed request path and answers {:error, {:missing_credentials, :webull}} without one. All twelve now gate through the same authenticated/1 → Auth.present?/1 helper the rest of the fake already used, checked before the argument validation they already did, matching Rest's own order — so Fake.get_news(symbols: ["AAPL"]) with no credentials is now a credential error rather than a success, and Fake.get_corporate_events() with neither is the credential error rather than :symbol_required.

  Why the earlier fix missed them. Assertion 17 gates on Core.AdapterContract's hardcoded @credentialed list — get_balances, get_accounts, get_fees, get_transfers, place_order, cancel_order, get_order, get_orders, get_trade_history — which names none of the twelve. The list predates the widened callback surface and was never extended with it, so a venue can pass assertion 17 with the whole options/watchlists/fundamentals/news/screener surface ungated. This was found by a cross-package audit that compared all five venue packages against each other, which also found the identical gap in dp_exchange_schwab's fake on its own widened surface — it is a property of the assertion's fixed list, not of either venue, and the durable fix belongs in Core rather than here.

• BREAKING: Fake let several credentialed account and order calls succeed with no credentials at all — the venue declares credential_benefit: :required and the fake did not honour it. Found by dp_exchange_core 0.1.57's new assertion 17 ("credential gate"), which reported get_fees/2 first; auditing every credentialed callback against its real Rest counterpart turned up the same defect on get_accounts/2, get_balances/2, get_transfers/2, get_transactions/2, get_positions/1, quantization/2, place_order/3, place_orders/3, preview_order/3, replace_order/4, cancel_order/3, get_order/3 and get_orders/2. Three different shapes of the same gap: get_fees/2 and get_accounts/2 discarded the credentials argument outright (_credentials) and checked nothing; get_balances/2 and get_transfers/2 gated only on fake_account(opts), an account-id check that is a different question from a credential check; the rest simply never referenced credentials at all. A consumer's own suite calling any of these with no credentials and asserting success was going green against behaviour the real venue does not have — every one of these hits a signed endpoint and gets a real 401.

  All now gate through DpExchange.Webull.Auth.present?/1 — the same %{app_key: <binary>, app_secret: <binary>} shape check Auth.headers/2 runs for every real signed request — checked in the same order the real Rest call checks it (account id before credentials, where both apply), so the fake's refusal point matches the real one, not just its final answer. get_fees/2's real counterpart (Rest.get_fees/2) builds no HTTP request at all — it is a published flat rate, not a query — so it never ran through Auth.headers/2 to get this check for free; it now calls Auth.present?/1 directly, which is the one behaviour change on the real facade in this fix (previously {:ok, _} for any input whatsoever, including no credential; now {:error, {:missing_credentials, :webull}} without one). Every other real Rest function was already correctly gated — only the fake had drifted from it.

  The refusal shape changed too, and this was wrong independently of assertion 17. Fake.get_price/2 and the rest of the market-data surface answered {:refused, :missing_credentials} for a missing credential. DpExchange.Core.Venue's own moduledoc reserves {:refused, reason} for the venue's own permanent word about a request it received — a request built with no credential never reaches the venue at all; Auth.headers/2 refuses it locally first. Every credentialed callback, market-data and account/order alike, now answers {:error, {:missing_credentials, :webull}} instead — Auth.headers/2's own return value, echoed rather than invented. market_status/1 is the one callback left unchanged: the real venue answers it with no credential too, so the fake doing the same is not a gap.

  FakeInjection.credentials_bypassed?/1 still short-circuits every one of these gates, unchanged, for a test that needs to skip the check deliberately.

• A clean-shutdown DISCONNECT warning fired on the ordinary shutdown path, on every test teardown in this package's own suite. Feed.terminate/2's DISCONNECT sweep (added the same day, above) logged Logger.warning/1 for every Socket.disconnect/2 failure without distinguishing why it failed. Two of disconnect/2's three error reasons are structural, not a failed send: :not_alive means the socket process was already gone — the ordinary shape of shutdown, since a shard's socket and the Feed supervising it are usually torn down together — and :calling_self can only happen through a test fixture handing terminate/2 its own pid, never in production. Neither is "the venue will see an abrupt disconnect instead of a clean one," which is what the warning said every time. A warning that fires on the normal path is noise that trains a reader to stop reading [Webull Feed] warnings at all — the same failure mode a red CI run for a non-failure was fixed for earlier in this package's history.

  Feed.terminate/2 now logs :not_alive and :calling_self at :debug, and warns as before for every other reason — a genuine send failure against a socket that was alive and reachable, where the venue really will see an abrupt disconnect. Nothing about when DISCONNECT is attempted changed; only which outcomes are worth a warning.

• capabilities/0 under-declared historical_timeframes and reports_trade_volume — both true crypto-only facts generalised to the whole venue. Found by a documentation-accuracy sweep (the one behind commit 94ea0a8) that deliberately left code untouched; this is the code-side fix it called for, run through the full gates. historical_timeframes named the eight crypto/event-contract widths only (1m 5m 15m 30m 1h 2h 4h 1d) and omitted 1w, 1M and 1y, which Rest.get_stock_bars/5's @stock_timespans map has served — and this package's own tests have exercised — on the equity, option and futures bars since that endpoint shipped. reports_trade_volume was unconditionally false, though Rest.get_price/3 with category: "US_STOCK"/"US_ETF" has always carried a real day-aggregate volume. Core.Capabilities has one flat list and one flat boolean for the whole package, with no way to say "true for equities, false for crypto" — reported upstream as a gap in dp_exchange_core's expressiveness rather than worked around here. historical_timeframes is now Rest.wide_timeframes/0 minus 1y (see below); reports_trade_volume is now true. Both fields' crypto exception is spelled out in measured_against, Webull's and Rest's moduledocs, and usage-rules.md, and both are still enforced per-call: a crypto or event-contract get_historical_prices/5 still refuses 1w/1M/1y rather than degrading to the nearest width, and a crypto get_price/2 still returns nil volume rather than a number.

  1y surfaced a genuine dp_exchange_core gap and is reported, not worked around. Rest.get_stock_bars/5 serves 1w, 1M and 1y, but dp_exchange_core 0.1.48's Timeframe.nameable/0 — the vocabulary Capabilities.new/1 validates historical_timeframes against — admits 1w and 1M beyond what it can bucket and has no entry for 1y at all. Declaring 1y here raises Capabilities.new/1's own validation, so historical_timeframes names ten widths, not eleven, and 1y stays reachable only by calling Rest.get_stock_bars/5/get_historical_prices/5 directly. This is a Core vocabulary gap, not a decision made here — flagged for dp_exchange_core to widen Timeframe.nameable/0 by one more width rather than silently narrowed to fit, invented a boundary rule for, or substituted with a neighbouring width. See webull.ex's @core_unnameable_widths for the full account.

  A consumer routing on the old declaration changes behaviour. One that read reports_trade_volume: false and routed all Webull volume work to another venue was needlessly discarding a real, reachable equity signal; one that read historical_timeframes as the ceiling of what get_historical_prices/5 could serve and never asked for 1w/1M on an equity, option or futures symbol was doing the same for those three widths. Neither previously received a wrong value — the under-declaration only ever caused a consumer to route around a call it could safely have made.

Removed — breaking

• MqttPacket.subscribe/2 deleted. Found by dp_exchange_core's new "16. internal wiring" conformance assertion: nothing in this package's lib/ ever called it. Traced rather than assumed dead — this venue's own documentation (docs/reference/webull/streaming-api.md) states plainly that "subscriptions are not managed over MQTT" and are HTTP calls instead (DpExchange.Webull.Subscription), so an MQTT SUBSCRIBE packet was never the mechanism this venue uses. SUBACK decoding (private, unreachable without a SUBSCRIBE ever going out) is removed with it. Anyone who called MqttPacket.subscribe/2 directly — an internal module, not part of the facade, but a public function until now — has it removed under them; the real subscription surface is unchanged: the facade's own subscribe/2.

Added

• The MQTT tick topic is now streamed as DpExchange.Core.Types.Trade — the third kind subscribe/2 delivers, alongside Quote and TopOfBook. Found by the same conformance assertion as above: QuoteProto.decode_tick/1 fully decoded the venue's documented Tick message and nothing ever called it — Subscription's default sub_types never asked the venue for TICK, and Socket had no tick-topic clause to route a payload to if one had arrived. A genuine venue capability, built and never wired end to end. Fixed in all three places it broke: Subscription's default sub_types now includes "TICK" (was ["SNAPSHOT", "QUOTE"], now ["SNAPSHOT", "QUOTE", "TICK"]); Socket decodes the tick topic to %DpExchange.Core.Types.Trade{}; Feed.kind_for/1 recognises it for coverage_by_kind/1. capabilities/0's streamable now includes :trades. Trade.id is always nil on this venue — the streamed tape carries no per-print identifier, matching get_trades/2's REST tape, which has the identical gap and already says so.

  TICK's inclusion in the default sub_types is read from streaming-api.md's topic table, not yet confirmed against the live venue — unlike SNAPSHOT/QUOTE, which are confirmed live (DpCryptoManagement's issue #19). capabilities/0's measured_against says so explicitly. If the venue answers TICK differently than documented, that surfaces through Feed's existing generic-subscribe- failure handling, the same as any other refusal Subscription hands back.

• DpExchange.Webull.live?/1 — whether the environment opts resolves to moves real money, resolved through the same precedence every call on this venue uses. Same shape and same reasoning as DpExchange.Gemini.live?/1. Found unwired: Environment.live?/1 existed and nothing in lib/ called it — a safety check built and never given a way for a consumer to reach it, since only the facade is public API on this venue.

• DpExchange.Webull.adjusted?/1 — whether bars of a timeframe on the equity/ETF tape are forward-adjusted. Rest.adjusted?/1 was already fully built and documented for exactly this question ("a caller stitching two widths together needs to know") but had no facade entry point to be called through; Core.Types.Candle has no field to carry the answer on the bar itself, so this was always meant to be asked of the package directly, not read off a returned candle.

Fixed

• A clean shutdown now sends MQTT DISCONNECT on every still-connected shard. MqttPacket.disconnect/0 built the packet and nothing ever sent it — found by the same conformance assertion, and the one violation worth reasoning through rather than just wiring: MQTT 3.1.1 §3.14 makes DISCONNECT the protocol's normal-close signal, and its absence is what makes a broker treat a closed connection as abnormal. That is a protocol fact, not a venue-specific one, and this venue's documentation is silent on whether it changes the ~1-minute session-retention window either way — nothing here claims it does. Socket.disconnect/2 sends the packet via WebSockex.send_frame/3, the only way to put a frame on an already-running Socket from outside its own callbacks; Feed.terminate/2 calls it once per connected shard, and only for the reasons GenServer treats as normal termination (:normal, :shutdown, {:shutdown, _}) — never for a crash, where extra socket I/O on a connection that may be the reason for the crash is the wrong trade against a fast supervisor restart. Feed.init/1 already traps exits (for shard-crash isolation), which is what makes terminate/2 actually run on an ordinary supervised shutdown, without needing its own handle_info({:EXIT, ...}) clause for that case.

  Found and fixed live during this work: WebSockex.send_frame/3 answers client == self() by raising WebSockex.CallingSelfError rather than returning an error, which a bare catch :exit does not stop. Socket.disconnect/2 now guards pid == self() explicitly and its catch clause is broadened to any exception kind, so it holds its own "never raises" contract regardless of how send_frame fails underneath it.

• capabilities/0's supported_instrument_types no longer hand-copies Rest.order_instrument_types/0's list — it derives from it. The prior comment ("Five, because the order builder builds five... so this cannot drift") asserted the equivalence without anything checking it; order_instrument_types/0 was itself unwired — nothing in lib/ called it, the declaration it was "exposed because" of read a separate literal instead. A private supported_instrument_types/0 now maps the order builder's five instrument types (:crypto, :equity, :option, :futures, :event) onto Core's four asset classes (:crypto/:equity both collapse to :spot) and the declaration is now the mapping, not a second list that could silently disagree with it.

• Environment.validate!/1 now checks membership in known/0 instead of carrying its own separate, literal [:production, :uat] guard — the same fix, same reasoning, as DpExchange.Gemini.Environment. known/0 existed and nothing in lib/ called it.

• SymbolFormat.to_canonical_symbol/1 and to_exchange_symbol/1 now read the mapping through mapping/0 instead of the private @mapping attribute directly — the module's own moduledoc has always argued both directions must run through one mapping so they cannot drift; the accessor sitting unused beside the attribute it exposes was exactly that risk, even though the two held the same value today. mapping/0 existed only as a conformance-suite seam and nothing in this package's own lib/ called it.

• Documented usage — children = [{DpExchange.Webull, []}], no :limiter anywhere — made every streaming HTTP call fail closed with "Rate limiter unavailable", silently, for the whole tree's lifetime. Supervisor's own init/1 started Feed with the bare opts the tree was given, so Feed's own resubscribe_opts — built once there and replayed on every reconnect and every 60-second blind resubscribe thereafter — carried no :limiter. Core.HttpClient.check_rate_limits/1 then resolved the limiter by Config.opt(opts, :limiter, DpExchange.Core.DefaultRateLimiter) — the bare module name — and nothing in this venue's supervision tree starts a rate limiter under that name, only under Supervisor.limiter_name(opts), registered one line above the broken Feed child spec. GenServer.whereis/1 on the bare name returns nil, and every subscribe, unsubscribe and blind resubscribe this package ever issued under the documented supervision form failed with {:error, "Rate limiter unavailable"} — proven live against a connected shard. Feed.subscribe/3's own synchronous path for an already-connected shard (touch_primary_shard/7, via reconcile_now/4) has the identical gap one layer up: it reconciles using the caller's own opts, not resubscribe_opts, so the facade's subscribe/2, unsubscribe/2 and update_symbols/2 needed the same default a caller who never names :limiter was always going to hit. Fixed in both places — Supervisor's own init/1 now defaults Feed's child spec :limiter the same way with_limiter/1 already does for every REST-backed facade function, and subscribe/2, unsubscribe/2 and update_symbols/2 now call with_limiter/1 too, where before they forwarded opts unchanged. Tests added in test/dp_exchange/webull_test.exs prove both halves: that a tree started the documented way wires Feed's own resubscribe_opts to the limiter it actually started, and that subscribe/2 reaches the venue without the caller naming one.

• The protobuf decoder's one nested field (Basic basic = 1) kept the FIRST occurrence on a repeated wire encoding instead of the LAST, inconsistent with scalar/1's own documented proto3 rule for a repeated scalar — the exact bug class this module's own moduledoc already records an incident for, now found in the one place that rule was not actually applied. decode_nested/1's list clause now filters to the binary occurrences and decodes the last one, matching scalar/1.

• A plain STOP_LOSS order built by place_order/3 carried no trigger price at all, and a TRAILING_STOP_LOSS order carried no trail distance — an architect-directed audit finding. replace_order/4's own field table (read from the vendor's reference) names stop_price for both STOP_LOSS and STOP_LOSS_LIMIT, and trailing_stop_step for TRAILING_STOP_LOSS — all three are real, @combinations-listed order types for equity, option and futures instruments. order_leaf/3's stop_for/2 only attached stop_price when the venue's wire name was "STOP_LOSS_LIMIT", and never attached trailing_stop_step for any order type at all. A caller placing a genuine stop-loss or trailing-stop order therefore had the one field that makes it that order type silently discarded before the request ever reached the venue — the single most expensive shape of substitution this family names, because the order still looks well-formed and the venue either rejects it for a reason the caller cannot connect back to a missing field, or (worse) accepts it with no trigger configured at all. No test exercised a plain :stop order's body at all, and the one existing :trailing_stop test asserted only order_type/time_in_force on the wire, never trailing_stop_step — the exact "test proves the wrapper, not the wire" seam this family has shipped bugs through before.

  price_for/2 was tightened the same pass: it used to attach limit_price for any non-MARKET order type, so a STOP_LOSS request built from a limit-order template (with :price still set) would have sent a limit_price the venue's schema for that order type does not have. It now attaches limit_price only for LIMIT and STOP_LOSS_LIMIT, the two types the vendor's own table lists it for.

  Fixed in lib/dp_exchange/webull/rest.ex's order_leaf/3, price_for/2, stop_for/2 and a new trailing_stop_step_for/2. Tests added in test/dp_exchange/webull/instrument_orders_test.exs assert the actual wire body for a plain STOP_LOSS (carries stop_price, no limit_price), a STOP_LOSS_LIMIT (carries both), and a TRAILING_STOP_LOSS (carries trailing_stop_step).

• The same audit found the read side of the same field missing too: stop_price never came back on an Order, anywhere. Core.Types.Order carries :stop_price for exactly this purpose, and this package sends it on place_order/3 and replace_order/4 (once the fix above landed), but:

  • to_placed_order/4 — the struct place_order/3 hands back immediately — never echoed it from the request, unlike price and quantity, which it already did.
  • to_order/1 — the real decode path behind get_order/3 and get_orders/2 — never read it from the venue's row at all, under either of the venue's usual stop_price/stopPrice names (the same dual-naming convention already proven correct for limit_price/limitPrice on the same row).
  • Fake.place_order/3 had the identical gap as to_placed_order/4, which would have let a consumer's suite go green against the fake while the real path answered nil — a usage-rules/testing.md violation ("never differently capable") this audit also checked for and found here.

  A caller placing a stop-loss or stop-limit order and then reading it back — by any of the three paths this package offers — got stop_price: nil regardless of what was sent or what the venue reported. Fixed in all three; tests added in test/dp_exchange/webull/order_mapping_test.exs (both wire-name forms, and that an ordinary order still carries nil rather than picking up a stray value), place_order_test.exs, and fake_test.exs.

• Two feed_test.exs tests synchronised on async work with a fixed Process.sleep/1 instead of an event — flaky under load, and exactly the anti-pattern this family has shipped CI-only failures through before. One slept 20ms hoping a send/2's handle_info had already run before asserting Process.alive?/1; fixed by replacing the sleep with a Feed.coverage/1 call, which — being a GenServer.call — queues behind the earlier send in the mailbox and so cannot return before it was processed, the same pattern already used elsewhere in this file. The other slept 100ms hoping isolate_crashed_shard/3 had already rebuilt state.shards before asserting on :sys.get_state/1 — :sys.get_state/1 answers over OTP's system-message channel and is not guaranteed ordered after a regular mailbox message, so the sleep was load-bearing and still a race even with it; fixed by subscribing to notices first and asserting assert_receive {:dp_exchange, :webull, %Notice{kind: :link_down}}, which isolate_crashed_shard/3 fans out synchronously inside the same handler that rebuilds the shard map.

• A third feed_test.exs test — the rate_limit_blocking regression test itself — flaked under full-suite load with a too-tight assert_receive window, not a Process.sleep/1 this time. "the blind resubscribe defaults to blocking" forces a real ~300ms wait inside acquire/3 (via exhausted_limiter/0's spent single-token bucket) before its stubbed HTTP call is even sent, on top of the process-hop latency test_helper.exs's own assert_receive_timeout: 1_000 exists to absorb — so the global 1_000ms default was not enough headroom for this test specifically, on top of that. It reproduced under a full 700-test async run (mix test --seed 849478) while passing in isolation every time. Given its own explicit assert_receive/2 timeout, widened to 5_000 — margin over the ~300ms wait, not a weakened assertion, since the test still fails if the message never arrives at all.

Added

• A shard's blind resubscribe failing for a generic reason now surfaces as a Core.Notice too, latched per shard — DpCryptoManagement's issue #23. The 60-second blind resubscribe timer (see the moduledoc's "The resubscribe timer must never fail-fast") already had two structured, caller-visible outcomes for a shard's HTTP subscribe failing: :oversubscribed rebalances silently, and {:invalid_symbols, symbols} gets its own :refusal notice (issue #24, above). Everything else an {:error, reason} could be — the rate-limiter throttling that issue #23 itself is ("Throttled by our own rate limiter (not the venue)"), an HTTP 5xx, a transport error — fell through handle_subscribe_result/3's catch-all clause to a Logger.warning and nothing else. Issue #23's own numbers are the cost of that gap: a node restart, all 4 shards linking up cleanly, then 58 consecutive blind-resubscribe failures across 13 minutes, every one the identical refusal, found only because a human went grepping this module's own log for the sentence it had been repeating the whole time.

  Core.PollingFeed's own :on_notice — added per DpCryptoManagement's issue #21, the poll-feed sibling of this same gap ("a feed that knows it has delivered nothing now says so on a channel a consumer can act on, not only in a log line") — is the pattern this follows, applied to a shard's resubscribe rather than a whole feed's fetch cycle: a %Core.Notice{kind: :coverage_change} fires the instant a shard's blind resubscribe crosses INTO this generic failure, and a severity: :info recovery notice fires the instant it crosses back OUT. :coverage_change is reused rather than inventing a new kind, for the same reason issue #21's own entry gives: "subscribed intent not becoming delivery is exactly what a feed delivering nothing is," and a shard whose resubscribe keeps failing is exactly that, one shard at a time.

  Latched per shard (state.resubscribe_failed, a MapSet of currently-failing shard indices) rather than globally, because each of this venue's up to 5 shards is its own independent MQTT session with its own independent failure and recovery schedule — a global latch would either swallow a second shard's own transition while the first stayed latched, or, left unlatched altogether, fire a fresh notice from every still- failing shard on every single 60-second tick during a widespread outage. A notice storm is its own defect, exactly as issue #21's design already established. The existing Logger.warning keeps firing every tick regardless, unchanged — this notice is additive, not a replacement. The latch for a crashed shard's index is cleared the moment isolate_crashed_shard/3 tears that shard down for reopening: the freshly reopened connection has never itself failed a resubscribe, and firing a "recovered" notice for it the moment its first resubscribe merely succeeds would be reporting a recovery from a failure the new connection never had — the crash itself is already reported separately, via the existing :link_down notice.

Fixed

• 17 venue-rejected symbols were blocking all 342 of a consumer's pairs from streaming, permanently — DpCryptoManagement's issue #24. Webull's subscribe is rejected per request, not per symbol: one symbol its streaming category does not carry fails the entire shard's batch. The venue answers HTTP 417 INVALID_SYMBOL and names the offending symbols in message ("The symbols does not exist in the category. [BNBUSD]" for one, a comma-separated bracketed list for several — confirmed against the real response shape and against DpCryptoManagement.Data.Collection.VenueRefusalsTest's own fixture), byte-for-byte identical every 60-second resubscribe tick, forever — because nothing downstream could act on it. Subscription.subscribe/3 collapsed the whole response into an opaque {:exchange_error, :webull, "HTTP 417: ..."} string, the treatment its sibling TOO_MANY_SYMBOLS_SUBSCRIPTION was deliberately spared (see that clause's own comment). Measured consumer impact: stream_covered 0/342, every pair falling back to REST polling, which is where the sustained HTTP 429 storm from issue #23 came from.

  Subscription now matches INVALID_SYMBOL specifically, parses the venue's own named symbols out of message, and converts them back to canonical form (SymbolFormat.to_canonical_symbol/1) before returning {:error, {:invalid_symbols, [canonical_symbol, ...]}} — mirroring :oversubscribed's existing structured shape. A message the parser cannot attribute to any symbol falls through to the previous opaque error rather than inventing an empty exclusion list — a rejection nobody can attribute is not one Feed can act on.

  Feed records each rejected symbol with a 24-hour expiry (state.rejected, overridable via opts[:rejected_symbol_ttl_ms] — deliberately the same order of magnitude as DpCryptoManagement.Data.Collection.VenueRefusals' own TTL for exactly this shape of fact: a venue's streaming catalogue is true at a point in time, not permanently) and excludes unexpired entries from plan_reshard/1's effective wanted set, so the next chunk built for an affected shard carries only symbols the venue actually accepts. A rejection is retried immediately within the same call via the existing reshard_step/4 retry (same mechanism as :oversubscribed), so a caller's own subscribe/3 still returns a clean :ok for the good symbols despite the shard's first attempt being refused. state.wanted is never pruned — only what's currently eligible for shard composition shrinks — so a symbol's exclusion lapses on its own once the TTL expires and the next resubscribe tick's resync/1 (now also run whenever state.rejected is non-empty) places it back into a shard, with nobody calling update_symbols/2.

  Also emitted as a Core.Notice — :refusal, Core's own documented kind for "a symbol the venue will not carry" — naming the rejected symbols in canonical form, since a symbol excluded from shard composition never appears (or fails to appear) in coverage/1 either way, and a notice is the only way a consumer learns why 17 of its 342 symbols stopped being tried. This is what lets a consumer's own venue-refusal cache (e.g. DpCryptoManagement.Data.Collection.VenueRefusals) populate for this venue for the first time.

Added

• coverage_by_kind/1, dp_exchange_core's new optional contract callback (~> 0.1.48, bumped from ~> 0.1.36). coverage/1 reports one :stream/:not_covered boolean per symbol, folding every streamed kind into it — which is exactly how a Coinbase venue in this family once reported full coverage for hundreds of symbols while one of its two streamed kinds had gone dark for nearly all of them, the discrepancy hidden behind the single boolean across two issues. This venue genuinely has the same shape to protect against, not a formality adopted only for cross-venue uniformity: every subscribe asks for both SNAPSHOT and QUOTE, and Socket decodes them on separate topics into two different structs that can go dark independently — snapshot into Core.Types.Quote (kind :quotes), quote into Core.Types.TopOfBook (kind :top_of_book). Feed now tracks arrivals per kind (delivering_by_kind, alongside the existing delivering) and derives the kind from the struct type that actually arrived (kind_for/1) rather than assuming it from capabilities/0 — so a third kind reaching the feed without a matching case here is logged loudly instead of silently folded into an existing one. Verified against Core's own conformance suite, assertion group 15, which asserts coverage_by_kind/1's symbol union equals coverage/1's keys exactly and that every kind key it reports is one capabilities().streamable declares — both now run against this venue for the first time (previously skipped: the callback did not exist) and both pass. Fake.coverage_by_kind/1 reports a single :quotes key, honestly: the fake's subscribe/2 only ever builds a Types.Quote, never a Types.TopOfBook, and "less capable is allowed, differently capable is not" means it must not claim a second kind it cannot produce.

Fixed

• capabilities().streamable said [:quotes]; this venue has always also streamed :top_of_book. Found while implementing coverage_by_kind/1 above, which requires naming a kind for every struct actually delivered — deriving one honestly for Core.Types.TopOfBook and then declaring it undeclared would have been exactly the kind of self-contradiction Core's own conformance suite checks for. Not a new venue capability: Subscription's default sub_types has always requested both SNAPSHOT and QUOTE, and Socket's quote-topic clause has decoded to Core.Types.TopOfBook since the bid/ask-as-price fix recorded in its own comment (a real quoted number is not a traded price — a bid is a resting order, a price is an execution). Both kinds have therefore always reached a subscriber; streamable simply never caught up when the TopOfBook fix landed. A consumer reading streamable: [:quotes] had no reason to expect a %DpExchange.Core.Types.TopOfBook{} on its subscriber's mailbox at all, and may not even have pattern-matched on one. usage-rules.md and README.md are corrected alongside — both are shipped in the Hex tarball and both previously implied a single streamed kind.

Documentation

• **README.md and docs/reference/webull/endpoint-inventory.md both stated stale endpoint counts — "44 of 87 :experimental, 43 :unsupported" — a snapshot from db17ff3 (2026-09-03 09:33) that went stale that same afternoon when 2f6c65b (2026-09-03 13:43) moved get_fees/2 and quantization/1 out of @not_ported, and neither document was told. Verified by calling capabilities/0 directly rather than reading @unsupported/@not_ported by eye: mix run -e against DpExchange.Webull.capabilities().endpoints on 2026-09-05 counts 46 :experimental and 41 :unsupported (87 total, unchanged), of which venue_does_not_serve/0 still names 30 as the venue's own absence and 11 remain not yet ported (was 13). Both documents corrected to 46/41/11; endpoint-inventory.md also now records the correction with its own evidence rather than silently overwriting the old figure.

  Audited against this release's other claim under the same suspicion — that order_type/time_in_force round-trip for all five declared values each, per the W1 fix below — by actually running the encode/decode round trip in code for every declared value of both, rather than trusting the fix's own description: all five order types (market, limit, stop, stop_limit, trailing_stop) and all five time-in-force values (ioc, day, gtc, gtd, fok) decode back to the atom that encoded them. Neither usage-rules.md nor README.md made a claim about this narrower than what capabilities/0 already declares, so there was no stale warning to remove — this is recorded here as the evidence that the audit looked, not as a document fix.

Added

• Fake wired to Core.FakeInjection — DpCryptoManagement's issue #14. Every function with a real success path (not an unconditional Venue.not_supported()) now checks a queued or always-set outcome first. Symbol-taking functions (get_price/2, get_top_of_book/2, get_historical_prices/4, get_order_book/2, get_trades/2, get_volume_profile/3, get_auction_imbalance/2, quantization/2, get_option_chain/2, get_option_expirations/2, get_financials/3, get_filings/2) support per-symbol targeting; the rest (get_symbols/1, get_balances/2, get_accounts/2, get_fees/2, get_transfers/2, get_transactions/2, preview_order/3, replace_order/4, market_status/1, get_positions/1, the watchlist functions, get_corporate_events/1, get_news/1, get_screener/2, place_order/3, cancel_order/3, get_order/3, get_orders/2) support whole-call injection. authenticated/1 also honours FakeInjection.credentials_bypassed?/1 for wiring-only tests, without changing the venue-faithful default for anyone who doesn't opt in. subscribe/2, unsubscribe/2, update_symbols/2 and place_orders/3 are deliberately not wired — each takes a list (symbols or orders) in one call, which whole-call injection cannot express partial failure for. Follows the reference implementation shipped in dp-exchange-robinhood; the shared mechanism itself lives in dp_exchange_core.

• Feed shards across multiple MQTT sessions — DpCryptoManagement's issue #13. A single session caps out at the venue's own stated ceiling ("Maximum number of subscribe tickers:100"); a consumer with more than 100 symbols on this venue could not reach full coverage through one session no matter how the HTTP calls were split, since the limit is per-session, not per-request. Feed now opens up to five sessions (the venue's own per-App-Key ceiling) and partitions symbols across them internally — the host still only ever calls subscribe/3 with a symbol list and never learns a shard, session id, or connection count exists.

  Adapted from dp-exchange-coinbase's own Feed, which shards for the identical reason: recompute from the full wanted set on every call, touch only what changed, one shard synchronous per call (its outcome is the reply) and the rest staggered. What differs here is the leaf operation — this venue's shard identity is also its MQTT session, so a brand-new shard waits for its own CONNACK (reusing the #9 fix, now per-shard) before its first HTTP subscribe means anything to the venue.

  A shard that rejects a batch as oversubscribed is rebalanced internally, never surfaced to the host as something to route around — the affected symbols move to another shard with room (opening one if needed) and the subscribe is retried. Per the design doc §3.5, this was an explicit architectural requirement, not a nice-to-have: the host must never be handed a shard index or session id to reason about. Only every shard already full and the venue still refusing — a genuine capacity ceiling this package cannot paper over — surfaces as a real {:error, {:capacity_exceeded, symbols}}.

  @pairs_per_socket is exactly the venue's own stated 100, not a guessed margin below it — see the design doc §3.1 for why padding an already-stated number would be the same unlabeled guess this family's conventions rule out elsewhere.

  See docs/design/2026-09-04_webull-sharding-and-fake-injection.md in dp-exchange-core for the full design.

• get_fees/2 and quantization/1 are implemented. Both had sat in @not_ported since Phase 2 with no comment recording why — DpCryptoManagement's own filed questions (issues #5, #6 against dp_exchange_core) were right that the classification did not distinguish "checked and absent" from "never looked".

  quantization/1 reads the same instruments/.../profiles/list endpoint get_symbols/1 already calls. Checked the vendor's live schema before writing anything: crypto and stock rows are disjoint, not the same shape with some fields blank. Crypto carries price_step, lot_size, min_trade_qty, max_trade_qty, min_trade_amt, max_trade_amt — all six. Stock/ETF carries lot_size alone; no price step, no per-unit or per-cash min or max anywhere on the row. A stock symbol now answers with quantity_increment and every other field nil, not the crypto shape reused because it was already written.

  get_fees/2 required checking two different products before answering. Trading API — the one this package speaks — has no fee-schedule endpoint anywhere in its surface, checked across Instruments, Accounts, Assets and Activities. What carries the name "Fees and Credits" lives entirely in Broker API, and is an administrative interface for a broker crediting or debiting a sub-account — not a schedule a caller queries, and out of reach on principle (D8) as well as on credentials. What the venue does publish, on webull.com/pricing: a single flat 1.00% crypto spread, charged by Webull Pay/Bakkt, the same for every account. get_fees/2 returns that captured, dated rate rather than a live per-credential lookup, because there is no live lookup to make — the rate does not vary by credential to look up.

Fixed

• The blind resubscribe timer's own rate-limit retry could never actually reach Core.HttpClient — DpCryptoManagement's issue #23. Live evidence, from a node restart: all 4 MQTT shards linked up cleanly, then 58 consecutive blind-resubscribe failures across 13 minutes, every one the identical refusal — {:exchange_error, :webull, "Throttled by our own rate limiter (not the venue) — retry after 1s; callers that can wait should set rate_limit_blocking: true"}. The refusal asks for a one-second wait; @resubscribe_interval_ms is 60,000 — so fail-fast (check/3) on this timer meant every tick was dropped for a full minute to avoid waiting a second. Measured consumer impact: 0 of 342 pairs streaming, all of them falling back to REST polling. It also made the venue's own transient, ordinarily self-healing INVALID_SYMBOL rejections on an initial subscribe permanent, because recovery from those runs through this same blind resubscribe.

  :rate_limit_blocking — the option Core.HttpClient.check_rate_limits/1 reads to choose acquire/3 over check/3 — was missing from every allowlist on the path a blind resubscribe actually takes: Feed's own resubscribe_opts (built once in init/1), replayable/2 (what carries it forward across every later subscribe), and Subscription.request_opts/1 (the last allowlist before Core.HttpClient itself). Fixing only the two in Feed — what the filed issue suggested — would have shipped a change that reads as a fix and does nothing: the option would still be silently stripped one layer down, by Subscription.request_opts/1, before Core.HttpClient ever saw it. All three now forward it. Only Feed's own opts default it to true — the resubscribe timer runs off a 60-second clock with nothing waiting on its result, so blocking for a second is free — following dp_exchange_robinhood's Feed precedent for the identical shape (its own issue #16) exactly: Subscription.request_opts/1 forwards the option without defaulting it, since a caller invoking Subscription directly, one-off, may legitimately want fail-fast, and this module must not decide that for it. An explicit caller-supplied rate_limit_blocking: false still wins over the default, at both init/1 and every later replayable/2 call.

  Proven end to end with a real, pre-exhausted Core.DefaultRateLimiter (named, passed via :limiter — a Config.put_override in the test process is not visible inside the separately-started Feed GenServer): the resubscribe's HTTP call reaches the stubbed venue in blocking mode by default, an explicit rate_limit_blocking: false at start keeps it fail-fast, and a later subscribe/3 call's own explicit false overrides the default on the very next resubscribe tick via replayable/2.

  Additional gap found while tracing this, and fixed for consistency: Webull.Rest.request_opts/1 (the allowlist for every other REST call this package makes — accounts, orders, market data) had the identical missing-allowlist gap, for the same reason a one-off Subscription.subscribe/3 call must not have blocking imposed on it: not defaulted, forwarded only, matching dp_exchange_robinhood's Rest.

• The socket's connect budget was inherited by accident, not chosen — family-wide defect sweep, W6. Socket.start_link/1 passed no options to WebSockex.start_link/4, so it silently accepted the dependency's general-purpose defaults: socket_connect_timeout: 6_000 and socket_recv_timeout: 5_000 (measured in deps/websockex/lib/websockex/conn.ex:10-11). That is 11 seconds of Feed's own 15-second @call_timeout spent on TCP and the HTTP upgrade before this venue's CONNACK is even awaited — and a shard is not usable until the broker accepts its session id, so the CONNACK wait and the HTTP subscribe both have to fit in the same call too. Feed is a named, shared process, so an unreachable venue made every other consumer's queued subscribe/unsubscribe/coverage wait out that window as well.

  Now set deliberately to 3s and 2s, chosen against that budget and documented with the arithmetic, both overridable and forwarded from Feed.start_link/1. This changes no failure semantics — start_link/1 still returns {:error, reason} synchronously exactly as before. The regression test asserts the values reach WebSockex and that overrides win, so a later refactor cannot quietly fall back to the dependency's defaults.

• order_type/time_in_force silently lost 2 of 5 declared values each on round-trip — family-wide defect sweep, W1. order_type_atom/1 and tif_atom/1 hand-listed only 3 of the 5 values their own forward encoders (@order_type_names, @tif_names) produce; capabilities/0 declares all five of each supported. A caller placing or reading back a :stop, :trailing_stop, :gtd or :fok order — every one a genuinely real order this package itself sent — got nil on that field, not an error. Fixed by deriving the reverse lookup maps from the same source maps the forward encoders use, so the two vocabularies cannot drift apart again; a value this package truly does not recognise still decodes to nil, unchanged. Fake.place_order/3 was also changed to round-trip an order's type and TIF through the real encode/decode functions (now exposed publicly for this reason) instead of handing the caller's atom straight back — the previous shape could not have caught this class of bug at all.

• A shard's socket crash took down the whole Feed, not just that shard — family-wide defect sweep, W2. Socket.start_link/1 links to Feed (ordinary WebSockex.start_link/4 behaviour), and Feed never trapped exits, so any abnormal socket exit — an uncaught exception in a callback, an internal websockex/gun failure — killed every shard's connection and every symbol's coverage, not just the one that failed. The opposite of the isolation reshard/4, resync/1 and the resubscribe timer all otherwise provide. Feed now traps exits; a crashed shard is logged, reported as a :link_down notice, any caller with a reply pending on it answered {:error, {:shard_crashed, reason}} rather than left to time out, and the shard is reopened at the same index with the same wanted symbols — the ordinary CONNACK-then-resubscribe path brings it back exactly as a first open would. Every other shard is untouched throughout.

• The unconditional 60s resubscribe (and every other control-plane HTTP call) ran inline inside Feed's own handle_call/handle_info, blocking the same mailbox that carries ticks — family-wide defect sweep, W3. Worst case, up to five shards' blocking Subscription.subscribe round-trips (measured ~118ms each) ran sequentially inside one handle_info, once a minute, stalling delivery for every shard — including shards the resubscribe was not even touching — for the whole duration, by design. Every such call now runs in its own task under a Task.Supervisor Feed owns; a caller's subscribe/3 still does not receive its reply until the real HTTP round trip finishes (unchanged observable contract, via a deferred GenServer.reply/2), but the mailbox stays free to keep draining ticks from every shard while that round trip is in flight. The oversubscribed-retry behaviour and the capacity-aware rebalance are unchanged.

• Shard assignment was recomputed from scratch on every call, so one newly-added symbol could touch every shard — family-wide defect sweep, W4. derive_shards/2 sorted the entire wanted set and cut it into fixed-size chunks; a symbol that happened to sort early shifted every symbol after it across every shard boundary, unsubscribing and resubscribing symbols that had nothing to do with the change — contradicting the moduledoc's own "touch only what changed" design claim and spending calls from the tightest budget in the family. derive_shards/3 now takes the existing shard assignment and is sticky: a symbol already assigned keeps its shard for as long as it is still wanted and still fits that shard's measured capacity; only genuinely new symbols, and anything just evicted by a capacity reduction, get placed into whichever shard (in index order) still has room.

• sub_types was sent lowercase, and every subscribe was rejected HTTP 417 UNSUPPORTED_SUB_TYPE "Subtype not supported:quotesnapshot" — DpCryptoManagement's issue #19, filed immediately after issue #18's fix unblocked the request enough to reach this validation for the first time. Subscription.post/4 defaulted "sub_types" to ["snapshot", "quote"], a comment mislabelling them as "the venue's own topic names" — they are not: quote/snapshot lowercase is the MQTT topic namespace a connected session receives on, a different field on a different protocol from the REST subscribe body's sub_types. The reporter's own retired in-repo client proved the working values: ["SNAPSHOT", "QUOTE"] uppercase, sent against this same endpoint for months. The venue's own error text is the two rejected values joined with no separator — "quote" + "snapshot" — which is what made the fix legible rather than a guess. Default changed to uppercase; nothing else about the request shape changed, since it was already sending a proper array, never a joined string.

• Every signed request went out with no Content-Type at all, and the venue's streaming-subscribe endpoint rejected every one with HTTP 415 "Request media type not support" — DpCryptoManagement's issue #18. Streaming never delivered a tick. Auth.headers/2 never declared a media type for any request, signed or not. The reported symptom was specifically the streaming subscribe/unsubscribe calls, but the same gap reached every JSON-bodied signed POST this package makes, place_order included — found while reading Auth.headers/2 directly rather than patching only the reported call site. Fixed at the source: Content-Type: application/json is added whenever a signed request carries a body; a GET's body is "" and stays bare, correctly. Not one of the six header pairs the signature itself covers, so this cannot desync a request from what was actually signed.

• Feed had no periodic resubscribe safety net, unlike the sibling dp_exchange_coinbase package this one's sharding adapts from — DpCryptoManagement's issue #17. This venue can stop delivering to an already-subscribed, already-connected session on its own — no error, no disconnect, no unsubscribe, nothing a health check can see. dp_crypto_management's own prior MQTT client found this empirically: a blind, unconditional resubscribe on a timer, independent of whether the wanted set had changed, took live coverage from 47 symbols back to ~240. reshard/4 alone cannot recover from this — it only touches a shard whose wanted symbol set changed, and re-asking for exactly what is already wanted computes an empty diff. Every connected shard's current subscription is now re-issued unconditionally every 60 seconds, matching the shape Coinbase's Feed already carries for its own reconnect case, applied here to a steady-state failure mode Coinbase does not have.

• Feed.fan_out/2 crashed on a subscriber registered by name — DpCryptoManagement's issue #15, same defect found on the sibling dp_exchange_coinbase package. subscribe/2's to: option accepts any value, and fan_out/2 called Process.alive?/1 on it directly — which only accepts a pid and raises on anything else. A consumer registering itself under a name (ordinary OTP practice) and handing that name to to: crash-looped the whole Feed GenServer on every delivery. Fixed by resolving a subscriber (pid or name) to a pid first, treating an unregistered name the same as a dead pid: silently skipped, never a crash.

• Feed dropped app_key entirely, and never waited for the venue's CONNACK before subscribing over HTTP — DpCryptoManagement's issues #8 and #9.

  Feed.init/1 kept only :url/:environment from its own start opts, so app_key never reached ensure_socket/2 — which silently defaulted to "" rather than refusing. Credentials arrive per call in this family, same as every other venue, so the fix reads app_key from the subscribe call's own credentials, and refuses ({:error, {:missing_required_field, :app_key}}) rather than opening a socket that would connect and then sit unauthenticated where nothing visible said why.

  Separately, ensure_socket/2 treated a live socket process as a ready socket — it returned as soon as Socket.start_link/1 did, which is once the WebSocket is up, not once the venue's CONNACK has actually arrived. The HTTP subscribe that followed could race the venue's own auth handshake and name a session id it had not yet registered. A reconnect already waited for the :link_up notice before replaying; the first-ever subscribe against a fresh socket now does too — the reply is deferred and answered from the same :link_up handler, rather than fired inline.

• decimal/1 (rest.ex, socket.ex) admitted "NaN", "Inf" and "-Inf" as real prices — DpCryptoManagement's issue #11. The Decimal.parse/1 fix for the "null" crash below was not a sufficient guard on its own: all three fully parse, and a NaN or Infinity flowing into downstream arithmetic as a real price is worse than the crash it replaced, since it poisons a calculation silently instead of failing where it happened. Both now also refuse via Decimal.nan?/1 and Decimal.inf?/1.

• Decimal.new/1 raised on a non-numeric price string — the exact crash filed as DpCryptoManagement's issue #3. Reproduced first: Decimal.new("null") raises, and a delisted Webull crypto pair is a real, previously observed shape that returns exactly that string for a price field. Fixed in both copies (rest.ex, socket.ex) with Decimal.parse/1, requiring the whole string be consumed — the family's established idiom, already used by chain_strike/1 elsewhere in this package.

  The lenient fix alone would have introduced a second, quieter defect: a malformed required field silently becoming nil instead of raising, which @enforce_keys does not catch. get_price/3, the socket's own emit_decoded/2, to_trade/2 and decode_bar/3 now refuse the record instead ({:error, {:invalid_decimal, field, value}} or {:error, {:missing_required_field, field}}), rather than delivering a Quote, Trade or Candle with a fabricated-looking nil in a field the type promises is real. One test fixture in order_book_test.exs had itself been supplying an incomplete bar (missing high/low) that only worked because the old lenient behaviour tolerated it; corrected to a complete bar rather than loosened back.

Documentation

• docs/reference/webull/endpoint-inventory.md's open question on the old /openapi/... paths is answered — family-wide defect sweep, W5. It previously said "whether the old paths still resolve is not established here." Live-probed unauthenticated against api.webull.com, 2026-09-05: the current paths answer from server: WEBULL OPENAPI with a 400 naming a missing signing header (reaches the real backend); the old /openapi/... paths answer from server: APISIX with a 404 Route Not Found (never leave the gateway in front of it). The old paths do not still resolve — the vendor retired the routes, not just their documentation — and this package no longer calls any of them (documented_paths_test.exs already guards that). No code change; the doc now records the answer with its evidence and date rather than leaving the question open.

• The :unsupported list is now split. venue_does_not_serve/0 names the 30 endpoints that are Webull's own absence — staking, one-step convert, funding rails, greeks, bulk cancel, position closing — each with the source and date behind it; 13 stay under @not_ported, including list_instruments/1, which the instrument profile endpoints already back through get_symbols/1 but which this callback has not been built against.

• README.md states what the contract covers — 44 of 87 callbacks :experimental across five asset classes.

• docs/reference/webull/endpoint-inventory.md's counts refreshed. It read "5 of 85" until this release, from the pre-Phase-8 capture.

Documentation

• Every negative this package makes is audited — docs/reference/webull/negative-claims.md, fourteen claims with the source and date consulted for each. Eleven hold; three were wrong, and all three were the same mistake: a true statement about the stock endpoint restated as a claim about the venue. The tell is in the wording — "the vendor states the stock snapshot does not serve it" is correct, and was used to justify a refusal that was not.

  It also records why this vendor's pages have to be rendered to be read: their parameter and schema tables are built in JavaScript, so a plain fetch returns the method, the path and a one-line description. An inventory captured that way looks finished and cannot be implemented from — which is exactly what the 2026-08-31 capture was.

• usage-rules.md is rewritten around the surface this release added. Its "what this package does not do yet" section listed order placement, balances and accounts as unimplemented; all of them ship. What replaces it points at capabilities/0 and states the one group that will not arrive — money movement, which this venue's API does not do.

  New sections cover the five categories and why their parameter sets differ, event contracts' two prices and four books, the option chain and the greeks that do not exist here, the twenty-three fundamentals endpoints, watchlists' three absences and their boolean, batch orders, and the token lifecycle.

• AGENTS.md gains a pointer to this package's own usage-rules.md.

Added

• place_orders/3 — batch order placement, POST /trading/orders/batch-place. This is the last open endpoint in the coverage plan's implementation phases.

  Not place_order/3 in a loop. The venue accepts the batch as one request; a caller that looped would reconcile N outcomes instead of reading one response, and the reconciliation is what goes wrong when the third of five fails.

  Both of the venue's limits are enforced before the request. A maximum of 50 orders, and equities only — its page says so in both cases. A batch over the cap is refused rather than split, because splitting turns one atomic request into several and undoes the only reason to call this. A non-equity order, or one outside the venue's own order matrix, is refused by index: a caller with fifty orders needs to know which.

  The result is per order, because a partial batch is the normal shape. The venue validates each and returns each; collapsing that into ok-or-error would let a caller believe "the batch failed" while holding four positions it does not know about.

  The vendor notes the endpoint is not available to every client, so a refusal can mean the account is not entitled rather than that the batch was wrong — the venue's own message is carried through unchanged.

• The token lifecycle — create_token/1, check_token/2 and oauth_token/3.

  A token that exists is not a token that works. create_token/1 returns one that is PENDING, and the venue's own note says verification happens through an SMS code in the Webull app — which needs a person and is not something this package can do. A caller treating a successful response as an authenticated session finds every subsequent call refused.

  check_token/2 is the only call that distinguishes the four states. PENDING has never been verified, EXPIRED has run out, INVALID was revoked or never existed — all three fail identically at the next request and each has a different remedy, so the venue's own string travels unmapped rather than being collapsed into a boolean.

  oauth_token/3 is one endpoint doing two jobs on a different host. opts[:code] exchanges the authorization code the host obtained; opts[:refresh_token] refreshes. Exactly one is required — both together is refused, because the venue would choose and the response would not say which. The host is oauth-open-api… and the body is a form, where every other endpoint in this package signs JSON: the same URL serves the host's code exchange and the package's refresh, which is why the boundary cannot be read off a path.

  Two expiries come back and they are not the same clock. expires_in is the access token's; rt_expires_in is the refresh token's, and it is the one that ends the session.

• Reference data and watchlists — thirty-eight endpoints: twenty-three fundamentals, six screeners, news summaries, and the eight watchlist calls.

  The fundamentals table is the design. Every one of the twenty-three takes symbol and category and differs only in what it adds, so the table names each endpoint's own extras and type/count are dropped on the endpoints that do not document them — an unknown parameter is at best ignored and at worst a refusal, and neither tells the caller which happened. get_fundamental/3 reaches any of them, fundamental_kinds/0 lists them, and a kind this venue does not publish is refused before a request is made.

  fiscal_period is translated through the venue's own legend — its page states 0=FY, 1=Q1, 2=Q2, 3=Q3, 4=Q4 — because the contract wants a label and the venue publishes a code. The raw integer stays in line_items, and a code outside the legend leaves the label nil rather than inventing one.

  get_financials/3 refuses a fundamentals kind that is real but is not a statement. :company_profile exists on this venue and answering get_financials/3 with it would put a profile in a statement's shape.

  get_corporate_events/1 has no :split. Webull publishes fund-splits for funds and nothing for equities, so a split kind would be answerable for some symbols and silently empty for the rest. Without opts[:kind] both calendars are read, which is two requests, and opts[:symbol] is required — these calendars are per issuer, not market-wide.

  get_news/1 is generated, not reported. The vendor's own description is "invokes LLM to generate news summaries", so each summary is a model's paraphrase and source names the venue rather than a wire. A caller quoting it is quoting a summary.

  A screener's rank is the position the venue returned the row in. Nothing is merged or re-ranked: two venues' "top movers" answer different questions. Each screener sends only the parameters its own page documents, and the venue's documented defaults are sent explicitly where it marks them required.

  Watchlists: three absences and a boolean. symbols is nil on a listing row — that endpoint names watchlists and does not read membership, where [] would say the watchlist is empty. name is nil on a membership read, because that endpoint does not return it. update_watchlist/2 refuses opts[:symbols] rather than silently skipping it: this venue's update endpoint touches properties only, and add_watchlist_instruments/3 and remove_watchlist_instruments/3 are the membership writes.

  Every watchlist write answers {"success": …} rather than an error status, so a false is a 200 that did nothing — reported as {:refused, :watchlist_write_rejected}. And creating with members is two requests: where the add fails, the watchlist exists and is empty, and that returns {:error, {:watchlist_created_without_members, id, reason}} carrying the id rather than an {:ok, watchlist} a caller would read as complete.

• Futures and event contracts — sixteen endpoints, and a reference document (docs/reference/webull/futures-and-event-contracts.md) recording every parameter and response field.

  The parameters needed a browser to read. These pages render their tables in JavaScript: a plain fetch returns the method, the path and a one-line description and nothing else, which is exactly what the 2026-08-31 inventory captured. A capture that stops at the method and path looks complete and cannot be implemented from.

  Futures route by US_FUTURES through the existing callbacks — get_price/2, get_historical_prices/4, get_trades/2, get_order_book/2 and get_volume_profile/3, each to its own endpoint with its own parameter set, which is not the union of all of them: futures bars take no real_time_required and no range, the futures tape and depth take no session flags, and the futures snapshot takes no extended-hours block.

  Event contracts add the venue's four-level hierarchy — list_event_categories/1, list_event_series/1, list_event_events/1, list_event_markets/1 — alongside list_futures_contracts/1 and list_futures_product_classes/1.

  Two event endpoints are deliberately not behind the contract's callbacks. An event tick carries a yes_price and a no_price and a side of yes/no; Types.Trade has one price and a side of :buy/:sell. An event book returns yes_bids, yes_asks, no_bids and no_asks; Types.OrderBook has two sides. In both cases the nearest mapping produces a number that looks right and belongs to the other instrument of a two-instrument market, so get_trades/2 and get_order_book/2 refuse US_EVENT and get_event_trades/2 and get_event_order_book/2 return the venue's own rows. The venue notes that a yes bid at X equals a no ask at 1−X; this package does not derive one side from the other, because a derived level cannot be told from a quoted one.

  Paged lists return their key. list_event_series/1 and list_event_markets/1 answer %{rows: [...], pagination_key: key_or_nil}; a bare list would make the last page and a truncated one look identical.

  status and tradable_status are two fields on an event market, and both survive: a market can be LISTING and NT at once, and one boolean would route an order at a market that is listed and not accepting one.

  Recorded as found, not resolved: the futures footprint page's category prose says "Only US_STOCK type queries are supported" while its own enum lists only US_FUTURES. The enum is what this package sends.

  asset_classes/0 gains :future and :event_contract.

• get_transactions/2 — the same /trading/activities/cash-activities/list endpoint get_transfers/2 narrows, asked without the filter.

  get_transfers/2 sends DEPOSIT,WITHDRAW,TRANSFER because the contract documents it as deposit and withdrawal history. This sends no activity_types at all, which is what asks the venue for everything it carries — TRADE, FEES, DIVIDENDS, TAX, INTERESTS, CORPORATE_ACTION, OPTION_EA, JOURNAL, EC_SETTLEMENT and OTHER beside the three. A default list here would be this package deciding what "every activity" means.

  The two are not interchangeable in either direction. A dividend and a deposit both credit cash and neither is the other: a caller computing contributions uses get_transfers/2, and one reconciling a balance uses this — summing the former leaves out the fees. Summing either is still not a balance; get_balances/2 is the authority.

Changed

• Core dependency moves to ~> 0.1.34, and eleven further callbacks are declared rather than missing — all of them absent, with the reason, checked against the venue's own endpoint list on 2026-09-01.

  Webull's published API moves no money. There is no payment-method endpoint at either scope, no bank registration, no crypto network list, no allowlist and no transfer between accounts; funding happens in Webull's own applications, which need a person. /trading/activities/cash-activities/list reports money that moved and does not move any. No fee-promotion list, FX publication, notional valuation or custody product either.

• The options surface: get_option_chain/2, get_option_expirations/2, and US_OPTION on the snapshot, bars and tape — /trading/instruments/options/contracts/list, /market-data/options/snapshots/list, /market-data/options/bars/list and /market-data/options/ticks/list.

  Three of those four were previously recorded as refusals, and the refusals were false negatives. This package held that US_OPTION "is refused: the vendor states the stock snapshot does not serve it" — true of the stock snapshot, and wrong about the venue, which publishes a separate option endpoint beside each one. Three tests asserted the refusal, which is how a claim about the venue survived being wrong.

  A chain is expiry × strike, and Webull publishes a flat list. The grid is rebuilt here, because a flat list is lossless in data and answers none of the questions a chain is asked. A contract this package cannot address is refused, naming the keys the venue actually sent — an expiry, a strike and a right are what address a contract, and a dropped row leaves a chain with a hole in it that looks complete. A strike listed with one side keeps a nil on the other rather than being absent.

  :underlying_price is nil: this endpoint lists contracts and does not quote the underlying, and fetching it separately would be two observations at two times presented as one.

  get_option_greeks/2 stays absent, and that one is real. Webull publishes no delta, gamma or implied volatility on any endpoint. Computing them would need a rate and a volatility surface it does not publish either — every number would be this package's model presented as the venue's, which is the most tempting substitution available here.

  asset_classes/0 gains :option.

• get_symbols/2 reaches the stock instrument profiles, /trading/instruments/stocks/profiles/list, routed by opts[:category]. Both endpoints paginate the same way and both are bounded — a truncated instrument list is the worst shape this family has, because every symbol in it is real and the missing ones are simply never traded.

• get_historical_prices/5 reaches the stock bars, POST /market-data/stocks/bars/list, routed by opts[:category]. A POST where the crypto bars are a GET, with its parameters in a JSON body.

  Daily and above are forward-adjusted; minute bars are not — the vendor states it, and it means these are not the same series at different resolutions. Stitching 1m bars onto a daily series across a split gives a discontinuity that is entirely real in each half and wrong where they meet, and nothing in the bar data says which side was adjusted. This package cannot fix that, so it reports it: adjusted?/1 answers it for a width, and returns nil for a width it does not serve rather than false, which would be a claim.

  real_time_required defaults to Y on this endpoint, unlike every other one here — that is an in-progress bar whose boundary has not happened yet. false is sent unless asked, matching the crypto path: a package that stored the venue's default would save a bar that changes after it is written.

  Three widths the crypto endpoint does not serve — 1w, 1M, 1y — are available here.

  The body sends count, start_time and end_time as numbers, not strings: the venue types them int32/int64, and a quoted number in a typed JSON field is a different value.

• get_price/3 and get_top_of_book/3 reach the stock snapshot, /market-data/stocks/snapshots/list, chosen by opts[:category].

  The two snapshot endpoints are not interchangeable and the category picks the path. Sending a stock symbol to the crypto endpoint returns nothing rather than an error, so passing the category through to one endpoint would have produced silence. US_OPTION is refused — the vendor states the stock snapshot does not serve it.

  The default is still US_CRYPTO, which is what this package served before its asset classes widened; changing it would silently re-route existing callers onto a different market.

  Volume is real on stocks and stays nil on crypto. The venue publishes no crypto volume anywhere, and nil says so where zero would claim a genuinely flat interval. The stock figure is the day's aggregate, which is what the venue names on this endpoint.

  extend_hour_required and overnight_required are sent explicitly on stocks so a caller reading nil knows it did not ask, rather than that the venue had nothing. Equity tickers bypass the canonical pair mapper, as they do on the order path.

• get_trades/2 — tick-by-tick public trades, /market-data/stocks/ticks/list.

  The venue documents side as "Such as: B S G L N" and defines none of them. B and S are unambiguous; G, L and N are documented nowhere the vendor publishes, so they map to nil — a real trade with an unknown aggressor. Folding them into the nearer of buy or sell would put volume on the wrong side of a delta, which is the number a caller reads a tape for.

  trading_sessions is required by the venue and defaults to RTH here, which is the session the rest of this package's price data comes from. There is no per-tick id on this endpoint and nil says so; broken is false because the venue publishes no bust flag.

• get_volume_profile/3 — stock footprints, /market-data/stocks/footprints/list. Traded volume split by price and by side within each interval.

  delta is the venue's own figure and is not recomputed from the totals. A venue that classifies some prints as neither aggressive buy nor aggressive sell reports numbers that do not reconcile, and that gap is information about its classifier rather than a fault to correct. The price maps keep the venue's own price strings — two strings that parse to equal decimals are the same level, and re-keying would silently merge two of its rows.

  Five widths, where get_historical_prices/4 serves more: 5s, 15s, 1m, 5m, 30m. Anything else is {:unsupported_timeframe, width} rather than the nearest one this endpoint happens to have. OVN is in the venue's session enum and its own note says it is unsupported, so it is refused rather than sent. real_time_required is false — completed intervals only, because an unfinished footprint's split still moves.

  Requires a separate Webull subscription, which the vendor states on the endpoint.

• get_auction_imbalance/2 — the NOII snapshot and the published series, /market-data/stocks/noii-snapshots/list. opts[:auction] is required: :opening and :closing are different auctions with different windows.

  Two endpoints. history: true reads /noii-bars/list instead of /noii-snapshots/list, and the bars publish the three prices and the time and nothing else — no paired quantity, no imbalance quantity, no side. Those come back nil, which says the venue did not publish them there; a caller computing a ratio over the series gets nil rather than a number that looks balanced.

  Outside the auction window the venue returns the last imbalance, not nothing — its own documentation says so. Both the venue's imbalance_time and this package's observed_at are carried, because together they are the only way a caller tells a live imbalance from this morning's. An undated one leaves venue_time nil rather than borrowing observed_at, which would make a stale imbalance look fresh.

  side is the venue's own code, carried as sent — it documents imbalance_side with the example "2" and does not say what 2 means.

  Requires a Nasdaq TotalView non-display subscription.

• get_order_book/2 — stock and ETF depth, /market-data/stocks/depths/list. The first endpoint of the equity market-data surface.

  The book is equities-only on this venue. The crypto snapshot publishes a top of book and nothing beneath it, and the vendor states US_OPTION is not supported here — so the category is checked before the request rather than after the venue's refusal.

  The attribution is dropped, and that is worth saying out loud. Each level carries the venue's order array of market-participant IDs with per-participant sizes, and broker names beneath that. Core.Types.OrderBook levels are {price, size}, so on a lit book this package discards who is quoting. The size that survives is the venue's own level size, not a sum over the participants — attribution can be partial, and the level size is the number the venue stands behind.

  A book the venue did not stamp is refused; a depth snapshot wearing the local clock cannot be told apart from a current one. sequence is nil, so a caller cannot use a REST book to detect a gap in a stream. overnight_required is always sent because the venue marks it required, and an omitted required parameter is a refusal a caller cannot read.

• BREAKING: this package is no longer crypto-only. asset_classes is [:crypto, :equity].

  The order builder now serves all five instrument types the venue names, and the matrix is per type because the venue's rules differ per type:

  CRYPTO   MARKET/IOC, LIMIT/DAY|GTC, STOP_LOSS_LIMIT/DAY|GTC
  EQUITY   MARKET, LIMIT, STOP_LOSS, STOP_LOSS_LIMIT, TRAILING_STOP_LOSS × DAY|GTC
  OPTION   as EQUITY minus TRAILING_STOP_LOSS ("Options not supported")
  FUTURES  as OPTION
  EVENT    LIMIT only, and DAY|GTC|IOC|GTD|FOK

  One matrix for all five would be wrong four times, and wrong in the direction that gets an order rejected after it was sent. {:unsupported_order_combination, instrument, type, tif} now names the instrument, and the fake enforces the same matrix from the same source — Rest.order_combinations/1 — rather than a hand-copied list that drifts.

  A request that does not say instrument_type is still crypto. Changing that default would silently re-route existing callers' orders onto a different market.

  Only crypto symbols go through the canonical pair mapper. An equity ticker is already the venue's own identifier, and pushing SOLV through a splitter that hunts for a quote currency would mangle it.

  Cash sizing (AMOUNT) is refused on futures and options, naming the instrument — the vendor states it for U.S. stock and event contract trading only. GTD carries an expire date and nothing else does; a missing one is left missing rather than defaulted, because a date chosen here would be an expiry the caller never asked for.

• preview_order/3 and replace_order/4. Both endpoints exist and both exclude crypto, which they refuse before sending — the vendor's own words, rather than a business error a caller cannot tell from a rejected order.

  preview_order/3 builds the same body a placement would, so a preview cannot diverge from the order it previews. It returns the venue's estimated_cost and estimated_transaction_fee, with the instrument type alongside them: for stocks and options the cost is total consideration, for futures it is initial margin, and a caller reading one as the other is off by the whole notional.

  replace_order/4 enforces the venue's per-type edit surface — a MARKET order takes quantity only, a trailing stop takes only its step — and reads the order back, because the venue's response carries no order and reporting the requested change as though it were confirmed is a different claim.

• get_transfers/2 — cash activities.

  The endpoint is much wider than transfers. It lists TRADE, FEES, DIVIDENDS, TAX, INTERESTS, CORPORATE_ACTION, OPTION_EA, JOURNAL, EC_SETTLEMENT and OTHER alongside DEPOSIT, WITHDRAW and TRANSFER. The contract asks get_transfers/2 for deposit and withdrawal history, and returning all of it under that name would be wrong in a way that costs money: a dividend and a deposit both credit cash and neither is the other, so a caller computing what it put in would count income as contribution. This asks the venue for the three, and opts[:activity_types] widens it.

  The venue's two constraints are enforced rather than discovered. Without a range it answers the last 7 days — its default, stated in the docs here so an empty list is not read as "no deposits ever". start_time and end_time must be in the same calendar year, and a cross-year range is refused up front rather than sent: a venue that silently truncates returns a real list missing the other half.

  Rows come back whole. activity_sub_type alone has 60-odd values carrying the difference between an ACH deposit and a wire, and no struct in this contract has anywhere to put them.

• get_accounts/2, get_balances/2 and get_positions/1. The package could not say what the credential holds or what it is exposed to.

  account_class is where this venue's breadth shows. The documented values are INDIVIDUAL_CASH, INDIVIDUAL_MARGIN, four IRA classes, CRYPTO, FUTURES and EVENTS_CASH — one credential reaches all of them. get_accounts/2 returns the venue's rows whole rather than filtered, because an account is not a value type here and normalising account_label away would lose the field a caller picking an account needs.

  available_balance is nil, deliberately. The venue publishes frozen_amount, held_amount (in transit), unsettled_cash, buying_power and available_withdrawal — five different numbers that do not agree. available_withdrawal is what can leave the account; buying_power is what can be traded and on a margin account exceeds the cash. Each is "available" to a different caller, and labelling one of them as the available balance would be right once and wrong four times. balance is cash_balance and hold is frozen_amount, both single-meaning fields of the venue's own. The rest is a gap in Core.Types.Balance rather than in this venue.

  A position's side comes from the sign of the quantity, via Position.from_signed_quantity/1. It is the only place this venue states direction, and a package that assumed :long because equities usually are would report a short that is exactly backwards with every number in it still plausible. liquidation_price and leverage stay nil — the venue publishes neither here, and nil means "not stated", never "no liquidation risk".

  get_balances/2 and get_positions/1 require opts[:account_id], as every account call on this venue does. get_accounts/2 takes none: the credential decides what it sees.

• place_order/3. This venue could not place an order; it can now.

  The venue documents which crypto pairs it accepts, and the list is short: MARKET takes IOC only, LIMIT and STOP_LOSS_LIMIT take DAY or GTC. There is no market GTC and no limit IOC. A pair outside that list is refused before the request is sent, so a caller gets both halves of what was wrong rather than the venue's business error.

  account_id is required and never inferred. An account is where the money is, and a package that looked one up and chose would place a real order against the wrong balance for a caller holding several. It comes from opts[:account_id] or the call fails.

  QTY and AMOUNT are different orders. Sizing in units and sizing in cash are named separately by the venue; giving neither is an error rather than a default, and giving both is refused as ambiguous. Cash sizing on a stop-limit is refused outright — the venue allows it on a buy and not on a sell, and accepting it on one side invites a surprise on the other.

  Crypto orders are sent as NORMAL combos only, which is what the venue supports; MASTER, OTO, OCO and OTOCO are equities groupings.

• cancel_order/3, get_order/3 and get_orders/2. The order lifecycle, which stopped at placement.

  This venue's order API is keyed on the client order id, not the venue's. Both /trading/orders/cancel and /trading/orders/get take client_order_id, so Order.id now carries it and place_order/3 was corrected to return it. Returning the venue's own order_id handed a caller an identifier that round-trips nowhere: place, then cancel, and the cancel fails on an id the venue does not accept.

  Open and historical orders are two endpoints, not one with a filter. /orders/open-orders/list and /orders/historical-orders/list answer different questions, and a caller asking for "orders" without saying which gets the open ones — the set that can still change. history: true asks for the other.

  account_id is required on all three, as it is on placement.

• Rest.post/4, which signs the body. Unlike Coinbase's URI-scoped JWT, this venue signs the payload, so the encoded string is built once and used for both the signature and the request. Encoding twice risks two orderings of the same map and a signature that does not match what was sent — which the venue would reject as an authentication failure rather than as the encoding bug it is.

Changed

• convert/4 and get_trade_volume/2 (Core 0.1.22) are declared unsupported. The venue publishes neither a one-step conversion nor the two-step quote/commit pair, and no account-volume report. Summing fills here would be this package's arithmetic rather than the venue's ledger, which is the number its fee tiers actually come from.

• Core 0.1.21's three new callbacks are declared, each with the venue checked. preview_replace/4 follows replace_order/4: the venue excludes crypto from the amendment endpoint, and crypto is what this package declares today — so it is unimplemented rather than unavailable, and it unblocks when this package's asset_classes widen to the stocks, options and futures Webull also serves. cancel_all_orders/2 has no endpoint at all: /trading/orders/cancel takes one client_order_id and the venue publishes no cancel-all or cancel-session. close_position/3 likewise — /trading/assets/positions/list reads positions and nothing closes one, at any asset class.

• Corrected a false claim about the venue. @unsupported said preview_order/3 "has no endpoint at all". /trading/orders/preview exists and is documented; what the vendor says is "For crypto trading, this feature is currently not supported", and the same sentence appears on /trading/orders/replace. /trading/orders/batch-place is stocks only and gated per client. They are unimplemented, not unavailable. asset_classes: [:crypto] describes this package as it stands, not a boundary of the venue, and treating the two as the same is the same mistake in a different place. Widening the package reaches all three.

• BREAKING: get_historical_prices/4 returns Core.Types.Candle structs, and the bar's time is opened_at. It returned bare maps keyed on :timestamp.

  timestamp did not say which time it was. A bar covers an interval, and the only time a venue publishes for it is the interval's opening — a caller reading timestamp as "when this bar closed" is off by exactly one interval, in a value that looks entirely reasonable. opened_at says which end it is. The struct also brings Candle.coherent?/1, which catches a high below the close at the boundary rather than downstream in a range or volatility calculation that will not error on it.

• Every endpoint moved to its documented path (D6). All five calls used an /openapi/… prefix that appears nowhere in Webull's current documentation; they were inherited from an older reading of the site.

  /openapi/market-data/crypto/snapshot       ->  /market-data/crypto/snapshots/list
  /openapi/market-data/crypto/bars           ->  /market-data/crypto/bars/list
  /openapi/instrument/crypto/list            ->  /trading/instruments/crypto/profiles/list
  /openapi/market-data/streaming/subscribe   ->  /market-data/streaming/subscribe
  /openapi/market-data/streaming/unsubscribe ->  /market-data/streaming/unsubscribe

  Three of the five changed more than their path, and a path-only rewrite would have compiled and passed:

  • snapshots stamp rows last_trade_time / quote_time; the timestamp reader accepted neither, so every quote would have failed :missing_venue_timestamp
  • bars renamed symbol to symbols and added a required real_time_required
  • instruments made category required and is now paginated

• get_symbols/1 follows pagination. The replacement returns one page per call, so a single request would have returned a plausible, silently truncated catalogue. The walk is bounded (@max_pages) and refuses a key that does not advance.

Added

• DocumentedPathsTest — asserts the documented paths are called and the /openapi/ ones are not. No test asserted any path before this, which is why the wrong ones survived.

Added

• Repo scaffold from the DpExchange standard; extraction pinned to the host's 553fa787 with per-file SHA-256, since the Webull subtree was dirty at extraction time — the third venue running.
• docs/reference/webull/streaming-api.md: the venue's MQTT-over-WebSocket streaming contract, committed verbatim, with its connection limits and protobuf schema.

Added — the package

• Market data (snapshot, bars, catalogue), streaming, and the whole supervision tree. 214 tests including Core's 28 conformance assertions, passing first run.
• Credentials are required for market data — every OpenAPI call is signed and there is no anonymous endpoint, so this is the family's first credential_benefit: :required.
• environment: :uat points REST at the UAT host. Streaming there refuses with {:streaming_unavailable, :uat} rather than falling back to production: the venue has no UAT broker, and a consumer testing against UAT that received production prices would be reading real market data believing it was fake.
• No trade volume anywhere on this venue, so volume is nil rather than 0. Zero would look like a real measurement of no trading.

Measured against the live venue, 2026-08-28

• The documented "TCP/IP" endpoint speaks TLS, not plaintext MQTT. Sending a well-formed MQTT 3.1.1 CONNECT to data-api.webull.com:1883 returns 15 03 01 00 02 01 00 — a TLS close_notify alert. The prior adapter reached the right conclusion (use WebSocket) from the wrong evidence ("never speaks MQTT", "no TLS handshake"); there is a TLS peer there, refusing a malformed ClientHello. wss://data-api.webull.com:8883/mqtt answers 101 immediately.