auto label is removed for flutter/flutter, pr: 123350, due to This PR has not met approval requirements for merging. You have project association MEMBER and need 1 more review(s) in order to merge this PR.

• Merge guidelines: You need at least one approved review if you are already a MEMBER or two member reviews if you are not a MEMBER before re-applying the autosubmit label. Reviewers: If you left a comment approving, please use the "approve" review action instead.

auto label is removed for flutter/flutter, pr: 123350, due to Validations Fail.

| Because mockito >=5.0.6 depends on test_api >=0.2.1 <0.5.0 and mockito >=5.0.1 <5.0.6 depends on test_api >=0.2.1 <0.4.0, mockito >=5.0.1 requires test_api >=0.2.1 <0.5.0.

it looks like we need to publish a new mockito compatible with the new test_api

I have an internal CL open to expand the constraints in mockito. After that I will sync to github and publish.

I have an internal CL open to expand the constraints in mockito. After that I will sync to github and publish.

Thanks!

A new mockito is published, I'll rerun failed github actions.

It looks like some of these tests have dependencies on mockito with an upper bound <5.4.0.

This package roll will indeed be breaking for any users with such constraints.

I cannot find any more actionable failures.

Here are a few that I don't think I can take action on:

customer_testing

https://github.com/flutter/flutter/pull/123350/checks?check_run_id=12398736701
https://github.com/flutter/flutter/pull/123350/checks?check_run_id=12398736506
https://github.com/flutter/flutter/pull/123350/checks?check_run_id=12398735697

https://ci.chromium.org/ui/p/flutter/builders/try/Windows%20customer_testing/51456/overview

Updating code in C:\b\s\w\ir\x\t\flutter_customer_testing.flutter_reactive_ble.bc4de0d5\tests\packages/flutter_reactive_ble/...
>> flutter packages get
| Resolving dependencies...
| Because no versions of functional_data_generator match >1.1.4 <2.0.0 and functional_data_generator >=1.0.1 <1.1.3 depends on analyzer ^1.5.0, functional_data_generator >=1.0.1 <1.1.3-∞ or >1.1.4 <2.0.0 requires analyzer ^1.5.0.
| And because functional_data_generator >=1.1.3 <1.1.4 depends on analyzer >=2.0.0 <4.0.0 and functional_data_generator 1.1.4 depends on analyzer >=2.0.0 <5.0.0, functional_data_generator ^1.0.1 requires analyzer ^1.5.0 or >=2.0.0 <5.0.0.
| And because mockito >=5.4.0 depends on analyzer ^5.2.0 and mockito >=5.0.6 <5.4.0 depends on test_api >=0.2.1 <0.5.0, if functional_data_generator ^1.0.1 and mockito >=5.0.6 then test_api >=0.2.1 <0.5.0.
| And because flutter_reactive_ble depends on flutter_test from sdk which depends on test_api 0.5.0, functional_data_generator ^1.0.1 is incompatible with mockito >=5.0.6.
| So, because flutter_reactive_ble depends on both functional_data_generator ^1.1.2 and mockito ^5.0.14, version solving failed.
ERROR: Could not run "flutter pub get" in packages/flutter_reactive_ble/, which was specified as an update directory.

The root cause is a package which is not compatible with the latest analyzer.
https://github.com/spkersten/dart_functional_data/blob/1d0b10a39bc6bc5ae5f94107c9154f12905774f5/functional_data_generator/pubspec.yaml#L11

I don't know what the policy is for these types of breakages. Do we disable the test until the third party package becomes compatible? I do not expect it will be feasible to release a version of combination of flutter_test, test_api, and mockito that will be compatible with any older analyzer. The package owner does not appear attentive to PRs.
spkersten/dart_functional_data#31 There hasn't been activity in the repo for a while.

Linux flutter_plugins

It looks like it is pulling an old version of flutter/packages which is missing flutter/packages#3544

I don't know how to check what commit of the other repositories it is using.

Linux analyze

ELAPSED TIME: 0.693s for bin/flutter update-packages --verify-only in .
▌07:34:36▐ Package Allowlist...
Exhausted heap space, trying to allocate 34359738384 bytes.
Unhandled exception:
Out of Memory
#0      List._allocateData (dart:core-patch/growable_array.dart:365:12)
#1      List._growToNextCapacity (dart:core-patch/growable_array.dart:396:5)
#2      _checkConsumerDependencies (file:///b/s/w/ir/x/w/%C3%81%20flutter%20sdk/dev/bots/analyze.dart:1775:17)
#3      _FutureListener.handleValue (dart:async/future_impl.dart:147:18)
#4      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:784:45)
#5      Future._propagateToListeners (dart:async/future_impl.dart:813:13)
#6      Future._completeWithValue (dart:async/future_impl.dart:584:5)
#7      Future.wait.<anonymous closure> (dart:async/future.dart:531:23)
#8      _FutureListener.handleValue (dart:async/future_impl.dart:147:18)
#9      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:784:45)
#10     Future._propagateToListeners (dart:async/future_impl.dart:813:13)
#11     Future._completeWithValue (dart:async/future_impl.dart:584:5)
#12     Future._asyncCompleteWithValue.<anonymous closure> (dart:async/future_impl.dart:657:7)
#13     _microtaskLoop (dart:async/schedule_microtask.dart:40:21)
#14     _startMicrotaskLoop (dart:async/schedule_microtask.dart:49:5)
#15     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:123:13)
#16     _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:190:5)

It looks like there is a bug, or a flake, in the flutter tool.

@christopherfujino - I currently don't have anything I can do to push this forward. Someone familiar with the flutter infrastructure and processes will have better success than me.

@christopherfujino - I currently don't have anything I can do to push this forward. Someone familiar with the flutter infrastructure and processes will have better success than me.

FYI @zanderso

@christopherfujino is out this week. Please file an issue to help him follow-up when he returns.

@zanderso - is there anyone who can help sooner? I think there is another high priority package roll for @bkonyi , and this package roll will block flutter users from getting the latest test and being able to try the latest checks. #123603

@goderbauer do you know if anyone might have cycles to take a look at this before @christopherfujino is back? AFAIU, this is less urgent than any tasks required for the branch cut, but I'd be happy to be corrected on that by @mit-mit or @anderdobo.

Exhausted heap space, trying to allocate 34359738384 bytes.
Unhandled exception:
Out of Memory

This issue looks like a circular reference between package:test_api and package:matcher.. The code walks down the tree and gets stuck in a loop.

I could open a PR to prevent it doing this and print a warning instead, though I don't know if the circular dependency is a concern?

customer_testing

I don't know what the policy is for these types of breakages. Do we disable the test until the third party package becomes compatible?

Have you emailed the listed contact point [1] for the failing package and showed them what is necessary to get their tests working again, ideally by sending a PR? If they remain unresponsive to that for 72h, we can as a last resort disable their tests.

Linux flutter_plugins

I don't know how to check what commit of the other repositories it is using.

This is the commit that gets used for the packages repo: https://github.com/flutter/flutter/blob/master/bin/internal/flutter_packages.version. Looks like your change (flutter/packages#3544) was picked up in #123778. I rebased this branch to pick up that latest roll and see if the check passes now.

Linux analyze

It looks like there is a bug, or a flake, in the flutter tool.

Let's see if the rerun triggered by the rebase fixes this...

[1] https://github.com/flutter/tests/blob/main/registry/flutter_reactive_ble.test

This PR fixes the script consuming all memory on my machine:

#123802

Whether the circular reference is reasonable though, I'm not sure :-)

though I don't know if the circular dependency is a concern?

It is expected temporarily. We will break the cycle in the next breaking version of test_api, but I'll first have to clean up a bunch of places in flutter/flutter where test_api was imported against the deprecation warning.

Have you emailed the listed contact point [1] for the failing package and showed them what is necessary to get their tests working again, ideally by sending a PR? If they remain unresponsive to that for 72h, we can as a last resort disable their tests.

I don't know specifically what they can do to get their tests working again. Most likely an dependency_override on analyzer could work, but the root cause is out of their control, and the author who can take action on the root cause is unresponsive. The failing package could choose to migrate off the apparently unsupported package, or try overriding the analyzer version. The impact of these decisions could relate to the development cycle within the project, and the tests may not be sufficient to know if any change I make impacts their development cycle.

I don't know specifically what they can do to get their tests working again. Most likely an dependency_override on analyzer could work, but the root cause is out of their control, and the author who can take action on the root cause is unresponsive. The failing package could choose to migrate off the apparently unsupported package, or try overriding the analyzer version. The impact of these decisions could relate to the development cycle within the project, and the tests may not be sufficient to know if any change I make impacts their development cycle.

You'll have to discuss that with the contact points of flutter_reactive_ble. I believe the maintainer of the package causing the trouble works for or with them, so if it is made clear to them that changes to a downstream package are needed to keep them in the flutter test repository, they may be able to do something about that. But if we don't contact them they will not be able to do anything about this.

Edit: for reference, here is our flutter/tests policy: https://github.com/flutter/tests#if-a-test-is-broken

Fix for the out of memory issue has landed (#123802)

Could we roll everything except test_api so there's less blocked on this?

I've prepared a PR here that's a full package roll but with test_api kept to the current version and everything is green (except the tree being red currently). If we land that, this PR becomes only the test_api roll which could be handled once the custom_tests issue is resolved?

#123854

Apologies! Thought i was closing my pull request :( reopened

@goderbauer - is there an automated way to get the roller bot to freshen this PR, or should I be looking at handling the merge conflicts?

I believe, if we close this PR the bot will create a new one with the latest roll on postsubmit of the next framework PR. I'm closing this to try that.