-
Notifications
You must be signed in to change notification settings - Fork 29.8k
[flutter_tools] more debugging for timeouts in break_on_framework_exceptions test #125584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[flutter_tools] more debugging for timeouts in break_on_framework_exceptions test #125584
Conversation
e4f01c6 to
66998f8
Compare
| /// package:test can be set and a helpful message used to help debugging. | ||
| /// | ||
| /// See https://github.com/flutter/flutter/issues/125241 for more context. | ||
| Future<void> _timeoutAfter({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should put this function somewhere global so we can use it to debug other possible flakes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we shouldn't make it too easy to do this, since it's against the style guide https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#never-check-if-a-port-is-available-before-using-it-never-add-timeouts-and-other-race-conditions.
Since this is library local, once we fix the bug affecting these test shards, we can delete the function, which we couldn't do if it was used to root cause various flake bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, that makes sense. Also just a general question, i see in the exceptException function we have called the _timeoutAfter function 4 times and each of those calls has a failure if it takes longer than 10 minutes.
What happens if each work call takes 4-5 minutes, which totals for 16-20 minutes which would be greater than the original CI 15 minute timeout... would this function still catch that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is intending to catch the situation where an isolate hangs and will never complete. If you look at the example I posted in my description, because the compiler failed, our test code will never see the event that it's waiting for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this isn't a general solution to all timeouts, but rather a very specific hack to try to get more information about the flakes in this particular library. Here the actual secret sauce was actually adding a printOnFailure in the _debugPrint() helper function that we were already calling but never actually printed on CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I also had to add my own timeouts, because I suspect printOnFailure() would never get run if the runner timed out the isolate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, that makes sense now, and yep, I saw the additional printOnFailure which made sense to me. Hopefully this can help identify the issue, LGTM
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
…work_exceptions test (flutter/flutter#125584)
Better debugging to investigate: #125241
When the
test/integration.shard/break_on_framework_exceptions_test.darttest times out, log out verbose logging to give clues as to why it did not complete.From one local run it looks like the test runner is failing to load a test file (when I checked the path locally, the file was there, and re-running the
flutter test ...invocation succeeded--in that the app threw an exception):