fix: bootstrap race condition causes dart example to be restored before its pubspec_overrides.yaml is written

[ahmednfwela]

Is there an existing issue for this?

• I have searched the existing issues.

Version

6.2.0

Description

Running melos bootstrap with repos that contain dart packages with examples can sometimes fail because of race conditions, where flutter will try to resolve the example project before melos has a chance to write its pubspec_overrides.yaml

e.g. when running melos bootstrap in a clean clone of the oidc package, you can see oidc_web_core/pubspec_overrides.yaml present, but oidc_web_core/examples/pubspec_overrides.yaml is not generated yet.

this causes the following exception:

melos bootstrap
  └> D:\packages\oidc

Running "flutter pub get" in workspace packages...
  ✓ oidc
    └> packages/oidc
  ✓ oidc_example
    └> packages/oidc/example
  ✓ oidc_android
    └> packages/oidc_android
  ✓ oidc_example_android
    └> packages/oidc_android/example
  ✓ oidc_core
    └> packages/oidc_core
  ✓ oidc_default_store
    └> packages/oidc_default_store
  ✓ oidc_desktop
    └> packages/oidc_desktop
  ✓ oidc_flutter_appauth
    └> packages/oidc_flutter_appauth
  ✓ oidc_ios
    └> packages/oidc_ios
  ✓ oidc_linux
    └> packages/oidc_linux
  ✓ oidc_loopback_listener
    └> packages/oidc_loopback_listener
  ✓ oidc_macos
    └> packages/oidc_macos
  ✓ oidc_platform_interface
    └> packages/oidc_platform_interface
  ✓ oidc_web
    └> packages/oidc_web
  ✓ oidc_example_web
    └> packages/oidc_web/example
  - oidc_web_core
    └> packages/oidc_web_core
       └> Failed to install.

Resolving dependencies...
Downloading packages...
# other deps commented for brevity ...
! oidc_core 0.8.0 from path ..\oidc_core (overridden in .\pubspec_overrides.yaml)
Changed 65 dependencies!
6 packages have newer versions incompatible with dependency constraints.
Try `dart pub outdated` for more information.
# this is the problematic line, where flutter tries to execute pub get on the example before melos is able to create its overrides ...
Resolving dependencies in `.\example`...
Because oidc_web_core_example depends on oidc_core ^0.8.0 which doesn't match any versions, version solving failed.
BootstrapException: Failed to install.: oidc_web_core at d:\packages\oidc\packages\oidc_web_core.

Steps to reproduce

1. git clone https://github.com/Bdaya-Dev/oidc && cd oidc
2. git clean -xdf to make sure all caches are removed
3. melos bs

Expected behavior

Melos should first create pubspec_overrides.yaml for all packages, then execute pub get on them in arbitrary order

Screenshots

No response

Additional context and comments

I tried running melos bootstrap --no-example, and the first problem was resolved, but then I am facing a different error:

d:\packages\oidc\packages\oidc\example\.dart_tool\package_config.json does not exist.
Did you run this command from the same directory as your pubspec.yaml file?
BootstrapException: Failed to install.: oidc at d:\packages\oidc\packages\oidc.

the only workaround I have found to solve this is to run the following commands in this specific order:

melos bs
melos bs --no-example

[spydon]

A workaround is to use path dependencies for the examples, since its not that important that it's not published anywhere (usually) explicit versions doesn't matter as much as for packages and apps.

[ahmednfwela]

yes, but I think the root problem is that melos is writing pubspec_overrides.yaml and then running pub get immediately, the correct approach would be to write out all the yaml files and then the order of running pub get will not matter

[spydon]

@ahmednfwela that could very well be, if you have time to investigate it further and provide a PR I can assign you to the issue?

[ahmednfwela]

sure, that would be great @spydon

[xsahil03x]

We faced the same issue when we used runPubGetInParallel: false in the melos.yaml. Removing that fixed it for us.
Not sure if that was the problem but this sure is an issue.

workflow run: https://github.com/GetStream/stream-chat-flutter/actions/runs/12549072449/job/34989464282?pr=2075

[ahmednfwela]

this just turns the issue into a race condition instead @xsahil03x

it may or may not happen depending on the threading capacity of the process

I was going to work on this issue, but I saw that pub workspaces were released , so I decided to just wait and see how they play with melos

[btrautmann]

this just turns the issue into a race condition instead @xsahil03x

it may or may not happen depending on the threading capacity of the process

I was going to work on this issue, but I saw that pub workspaces were released , so I decided to just wait and see how they play with melos

Ironically we are finding what I think is a similar race condition when using melos in our migration to pub workspaces. We are finding that for some reason, our example projects are randomly receiving dependencies from elsewhere in the workspace and this causes a pod install to fail later because an example project is depending on things that it shouldn't. I haven't root caused it to melos yet, but we found that removing melos from the specific script in question resolved the issue.

To be more specific, the .flutter-plugins and .flutter-plugins-dependencies files in the example project contained dependencies that it shouldn't, which then caused pod install to fail because that invokes logic from flutter tooling's podhelper.rb which tries to depend on every pod found in those plugin files.

[spydon]

@btrautmann I'm fairly sure your issue is unrelated to this issue, so it would be better to create a new issue for it.
Your issue sounds more related to pub workspaces, potentially in combination with melos.

[btrautmann]

@btrautmann I'm fairly sure your issue is unrelated to this issue, so it would be better to create a new issue for it. Your issue sounds more related to pub workspaces, potentially in combination with melos.

Yeah I'm trying to create a repro but given the fact that I believe it to be a concurrency issue, the repro would need to be fairly involved (as is our workspace). I only commented on this issue in response to the prior comment about hoping that pub workspaces would fix the race condition they're experiencing, but I think it opens the door for potentially different race conditions.