Fix a unit test in DartDocumentationProvider #175
Conversation
This is expected to resovle the flaky presubmit failures.
| // "dart:html" -> "dart-html" | ||
| if (dartUrl.startsWith(DartUrlResolver.DART_PREFIX)) { | ||
| return "dart-" + dartUrl.substring(DartUrlResolver.DART_PREFIX.length()); | ||
| String url = dartUrl.substring(DartUrlResolver.DART_PREFIX.length()); |
There was a problem hiding this comment.
I'm trying to wrap my head around how this change would address flakiness...
Could you help me understand?
Sorry if I'm just being thick!
There was a problem hiding this comment.
No worries... I should have included more information in the PR comments.
Here is an example of the failure in our bots: https://github.com/flutter/dart-intellij-third-party/actions/runs/20836418630/job/59862007406?pr=198
The fix adds a normalization step that truncates the dart: URL at the first slash using substring.
- Before: dart:core/int.dart -> dart-core/int.dart (mismatching dart-core)
- After: dart:core/int.dart -> dart-core
This ensures that regardless of whether the resolver returns the library URI or a specific part file URI, the generated documentation key remains consistent (dart-libName), preventing hash/lookup mismatches that caused the test flakiness.
There was a problem hiding this comment.
Fascinating! So what resolver we get is non-deterministic? Is that why the test only sometimes fails?
There was a problem hiding this comment.
Also: are we totally sure normalization is the right thing to do? I admit I don't know but my gut is that if a test is flaky, I'd expect a change there and not in the class under test -- unless the flakiness indicates a bug? Do you think that's what's going on?
2 participants
This is expected to resovle the flaky presubmit failures.