test: POSIX-normalise paths in link_priority_structural_test (fixes 4 Windows-only failures) - #247
test: POSIX-normalise paths in link_priority_structural_test (fixes 4 Windows-only failures)#247dev-noaman wants to merge 1 commit into
Conversation
These four tests fail on Windows and pass on CI, so the breakage is invisible
to the project and costs every Windows contributor the same half hour.
`Directory('lib').listSync()` returns NATIVE separators, so on Windows the
collected keys are `lib\ble\ble_engine.dart` while every assertion in the file
is written `lib/ble/ble_engine.dart`. Two failure shapes follow:
Expected: a string starting with 'lib/ble/ble_engine.dart:'
Actual: 'lib\ble\ble_engine.dart:781'
and, worse, `_engine()`'s `.firstWhere((e) => e.key.endsWith('ble/ble_engine.dart'))`
throws a bare "Bad state: No element" that names neither the file nor the cause.
Normalised once where the paths are collected, rather than at each assertion:
nothing this file pins is platform-specific, so the paths it reasons about
should not be either, and the assertions keep reading as the single spelling
they already use. Replacing `Platform.pathSeparator` rather than a literal
backslash keeps it a no-op on POSIX instead of corrupting a filename that
legally contains one.
Behaviour is otherwise unchanged. Verified the test still bites: dropping a
second `requestConnectionPriority` call into lib/ fails it as before, and the
diagnostic now reads `[lib/_tmp_violation.dart:4, lib/ble/ble_engine.dart:797]`
rather than a mix of separators.
Before: 1 passed, 4 failed (Windows). After: 5 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrVjCqVDMANK5sa5eyjATw
|
Warning Review limit reached
Next review available in: 24 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Green on CI, red on Windows
link_priority_structural_test.dartcollectslib/**.dartwithDirectory('lib').listSync(), which returns native path separators. Every assertionin the file is written POSIX-style, so on Windows 4 of its 5 tests fail:
and the helper
throws a bare
Bad state: No element— which names neither the file nor the cause,so the first guess is that something in
ble_engine.dartactually broke.CI runs on Linux, so
mainis green and this is invisible to the project. It just costsevery Windows contributor the same half hour, on a test that is doing its job correctly.
Same class of thing as #246 — not a bug in the repo's logic, a bug in what the repo
assumes about the machine it is built on.
Fix
Normalise once where the paths are collected, not at each assertion:
Two deliberate choices:
so the paths it reasons about shouldn't be either. The five assertions keep reading as
the single spelling they already use, and a future assertion can't reintroduce the bug
by forgetting to normalise.
Platform.pathSeparator, not a literal\. On POSIX this is a no-op, whereas ablanket backslash replacement would corrupt a filename that legally contains one.
Verification
Before: 1 passed, 4 failed (Windows). After: 5 passed.
The test still bites. I dropped a second
requestConnectionPrioritycall intolib/and confirmed it still fails — a path fix that quietly stopped the check fromcatching anything would be worse than the bug:
As a side benefit the diagnostic now reads in one consistent spelling instead of mixing
separators.
No behavioural change on Linux/macOS:
Platform.pathSeparatoris/there, so thereplacement is identity.
no_debug_only_apis_test.dartuses the same grep approach but asserts no paths, so it isunaffected — this is the only file with the issue.