You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
▌17:09:37▐ Package Allowlist...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Warning: transitive closure contained non-allowlisted packages:
[frontend_server_client]
See dev/bots/allowlist.dart for instructions on how to update the package allowlist.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
I see this on 07fc1a6a48 but I don't think this is related to a framework commit...
Git bisect points to f6f59c5, which is when we added the allow list, which suggests that somehow our fixed pins are not working and we got caught by an upstream change. That's not supposed to be possible.
frontend_server_client was added in dart-lang/test#1399. I'm not sure why the script picked up an unpinned version, but it looks legit to be added to the allowlist in the meantime. @jonahwilliams@jakemac53 do you agree?
I suspect this is a bug in the --transitive-closure script in update packages. I'll plan on taking a look, but in the meantime we can add that package to the allowlist since its a dev_dep anyway. Maybe we should count dev deps separately anyway.
This is how it happens: update-packages tries to avoid pinning "transitive dependencies" in the synthetic pubspec, since its goal is to allow easy upgrades to the latest version of everything. --transitive-closure just wants to show the dependencies as they exist today, but re-uses the update-packages logic to generate a synthetic package. Since test_core is not pinned in this synthetic package, we version solve to the latest version and show frontend_server_client in the dep list - even though nothing in our repo is updated to use this
I don't see any alternative to pinning it. If it becomes a problem we can copy it into package:test_core instead, but I think it should be fine to pin for now.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
jmagman commentedon Apr 22, 2021
test_core 0.3.20 was just published an hour ago and is the package with the frontend_server_client dependency, unless I'm missing something.
Hixie commentedon Apr 22, 2021
Git bisect points to f6f59c5, which is when we added the allow list, which suggests that somehow our fixed pins are not working and we got caught by an upstream change. That's not supposed to be possible.
jmagman commentedon Apr 22, 2021
frontend_server_clientwas added in dart-lang/test#1399. I'm not sure why the script picked up an unpinned version, but it looks legit to be added to the allowlist in the meantime. @jonahwilliams @jakemac53 do you agree?Hixie commentedon Apr 22, 2021
dev dependencies should be pinned too, right?
jonahwilliams commentedon Apr 22, 2021
I suspect this is a bug in the --transitive-closure script in update packages. I'll plan on taking a look, but in the meantime we can add that package to the allowlist since its a dev_dep anyway. Maybe we should count dev deps separately anyway.
jonahwilliams commentedon Apr 22, 2021
This is how it happens: update-packages tries to avoid pinning "transitive dependencies" in the synthetic pubspec, since its goal is to allow easy upgrades to the latest version of everything. --transitive-closure just wants to show the dependencies as they exist today, but re-uses the update-packages logic to generate a synthetic package. Since test_core is not pinned in this synthetic package, we version solve to the latest version and show frontend_server_client in the dep list - even though nothing in our repo is updated to use this
jakemac53 commentedon Apr 22, 2021
I don't see any alternative to pinning it. If it becomes a problem we can copy it into package:test_core instead, but I think it should be fine to pin for now.
jonahwilliams commentedon Apr 22, 2021
So the bug is on our end, and I'll take a look at fixing that - in the meantime we can add it to the allowlist to unblock the tree
jmagman commentedon Apr 22, 2021
Workaround #80912 merged, tree should be unblocked.
Lowering priority.
7 remaining items
matanlurey commentedon Jul 21, 2025
The allow-list check does use
pub depscurrently.github-actions commentedon Aug 4, 2025
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.