tests: the selectable transport order is H1-first, matching the SDK - #334
Merged
Conversation
TransportStatsTests asserted [.h3, .h1, .dns, .dnsPump] in four places
that read their value from the SDK. The SDK's order is H1-first, and it
is explicit about it:
// SelectableTransportModes returns the modes a policy can select ...
// in the default H1-first preference order.
return []TransportMode{H1, H3, Dns, DnsPump}
Its own Go test asserts exactly that sequence, and
DefaultTransportModePriority is H1=1, H3=2, Dns=3, DnsPump=4. This file's
own source agrees too -- TransportSettingsStore.swift documents
`selectable` as "the SDK's default preference order (h1, h3, dns, then
dns pump)". Only the expectations disagreed.
The four corrected assertions all read arrays built by
TransportType.fromSdk():
settingsSnapshotFollowsTheSdkPolicy autoTransports, enabledTransports
selectableTransportsAreTheSdkDefaultOrder TransportType.selectable
TWO OTHER [.h3, .h1] ASSERTIONS ARE LEFT ALONE, deliberately:
:44 distribution.used -- usage order from a mock's byte counts, not
the selectable order. h3 really is used more there.
:267 constrainedTransports is a Set<TransportType>, so the literal's
order is not compared at all. It passes either way.
Neither was failing, and changing them would have implied a rule that
does not exist.
Nothing in the app's non-test code assumed H3-first: the only other
H3-first ordering is TransportType's own `allCases`, which is the enum's
stable declaration order and a separate concept from the SDK's
preference order.
These have presumably been red for a while. urnetwork/apple had no CI
until #333, so nothing ever ran them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MAXFxG1EK4jTxQ1iW73BUr
Ryanmello07
marked this pull request as ready for review
August 22, 2026 05:45
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The two
TransportStatsTestsfailures onmainare wrong expectations, not aproduct bug. Fixing them makes the suite green.
What was wrong
Four assertions expected
[.h3, .h1, .dns, .dnsPump]for values that are readfrom the SDK. The SDK is H1-first and says so explicitly:
Its own Go test asserts that exact sequence, and
DefaultTransportModePriorityis H1=1, H3=2, Dns=3, DnsPump=4.
This repo already agreed.
TransportSettingsStore.swiftdocumentsselectableas "the SDK's default preference order (h1, h3, dns, then dnspump)". Only the test expectations disagreed with both.
The four corrected lines all read arrays built by
TransportType.fromSdk():settingsSnapshotFollowsTheSdkPolicyautoTransports,enabledTransportsselectableTransportsAreTheSdkDefaultOrderTransportType.selectableTwo other
[.h3, .h1]assertions are deliberately untouched:44—distribution.usedis usage order from a mock's byte counts, notthe selectable order. h3 genuinely is used more there.
:267—constrainedTransportsis aSet<TransportType>, so the literal'sorder is never compared. It passes either way.
Neither was failing. Changing them would have implied an ordering rule that does
not exist.
Scope
No non-test code assumed H3-first. The only other H3-first ordering in the app is
TransportType.allCases, which is the enum's stable declaration order — aseparate concept from the SDK's preference order, and correct as it stands.
These were presumably red for a while: this repo had no CI until #333, so nothing
ever ran them.
For the reviewer
Worth a second opinion on one thing: I concluded the SDK's H1-first order is the
intended product behaviour, on the strength of the SDK's comment, its Go test,
its priority table, and this repo's own doc comment all agreeing. If the product
intent is actually H3-first, then the fix belongs in the SDK instead and this PR
should be closed.