Can we access your project?
Current Behavior
The "Update dependencies to the latest version" operation is stuck on an endless spinner and never completes. Analyzer Status shows "Pub get failed."
The spinner persists across full project close/reopen, app restart, and reverting to earlier snapshots — including snapshots from before the conflict was introduced. Because reverting project state does not clear it, this appears to be a wedged platform-side resolution job, not a project-state issue. This matches the pattern in #6331.
Root cause of the underlying conflict, from the analyzer error: the installed FlutterFlow Library "ElevenLabs Conversational AI Library" (v1.2.0) depends on mime_type ^1.0.1, while the project's FlutterFlow-managed Pub Dependencies pin mime_type at exactly 1.0.0. These are unsatisfiable together, so version solving fails. The mime_type 1.0.0 entry is in the FlutterFlow-managed Pub Dependencies list (not Custom Pub Dependencies) and is not user-editable.
Exact analyzer message:
Because the_six_pages depends on elevenlabs_conversational2_x2dkep from path which depends on mime_type ^1.0.1, mime_type ^1.0.1 is required. So, because the_six_pages depends on mime_type 1.0.0, version solving failed. Failed to update packages.
The project was analyzer-green earlier today. The conflict appeared immediately after clicking "Update dependencies to the latest version" during a Firebase config regeneration. The library version did not change (it has been 1.2.0 throughout) — the update operation appears to have bumped a transitive dependency to a release that now requires mime_type ^1.0.1, introducing the conflict and then wedging the resolution job.
Expected Behavior
flutter pub get resolves successfully and the project returns to a buildable, analyzer-green state, as it was earlier today before "Update dependencies to the latest version" was clicked.
Specifically: a compatible dependency set provably exists (the project was green with library v1.2.0 and mime_type 1.0.0 coexisting), so the resolver should be able to settle back to that working set rather than remaining wedged on an unsatisfiable upgrade target.
Ideally, the FlutterFlow-managed mime_type pin would be reconciled with the library's ^1.0.1 requirement — either by raising the managed pin to a version that satisfies ^1.0.1, or by advising the supported way to override it at the project level.
Steps to Reproduce
Have a FlutterFlow project that imports the Marketplace library "ElevenLabs Conversational AI Library" v1.2.0 (Marketplace item rwPaVMENBqTorJiznewx, package elevenlabs_conversational2_x2dkep), which declares a dependency on mime_type ^1.0.1.
Confirm the project is analyzer-green in this state (it was, as of earlier today).
Trigger a dependency re-resolution — in this case, regenerate Firebase config files (Settings → Firebase → Regenerate Config Files), then click "Update dependencies to the latest version."
Observe the analyzer error: version solving fails because the FlutterFlow-managed Pub Dependency mime_type 1.0.0 cannot satisfy the library's ^1.0.1 requirement.
Observe that the "Update dependencies to the latest version" spinner then runs indefinitely and never resolves.
Confirm the spinner persists after: full project close and reopen; app/browser restart; and reverting to earlier snapshots (including pre-conflict snapshots). The wedged state does not clear through any user-available action.
Reproducible from Blank
Bug Report Code (Required)
IT5fz8r13ItPxOEE+KX6cfkwmioXQ1M7ULgriO0bEAgbIrnqP7AUPs/7N1BJYteFT2xcJWH/ingJzPTTv9ieUcc4BxCuGbY6wq9XdwvyLUyuRr6lPoeBPHFQRN5TGm3C1qWjuhV7A/NzWFllwzumJOeRY3PUHb7vCm07O/mXMpPJ+UKbGQ22VRcw7zcADmreTI5ODEz25eKMrop5yfj/0w==
Visual documentation
[
](url)
Environment
- FlutterFlow version: v7.0.14
- Platform: Desktop
- Browser name and version:
- Operating system and version affected: Windows 11
Additional Information
That's a real and reasonable fear, so let's write this field to do two jobs: convey genuine impact (which raises priority) and preempt the "just remove the library" non-answer you're worried about. The way to prevent that answer is to make clear, in their own technical terms, that a compatible resolution provably exists — so the correct fix is reconciling the pin, not abandoning the integration.
Here's what to paste:
This is blocking active pre-launch development on a project in TestFlight and Google Play closed testing. The voice feature built on this library is a core part of the app, and the entire backend integration (token endpoint, WebRTC session auth) is already complete and working — the only blocker is this dependency-resolution wedge.
I want to flag one thing to help triage: a compatible resolution provably exists. This exact project was analyzer-green earlier today with library v1.2.0 and mime_type 1.0.0 coexisting. The conflict only appeared after "Update dependencies to the latest version" pulled a transitive dependency up to a release requiring mime_type ^1.0.1. So the library and the managed pin are not fundamentally incompatible — the working set existed and was stable until the upgrade churn.
For that reason, removing or downgrading the library is not the resolution I'm looking for, and shouldn't be necessary. What I need is either (a) the wedged resolution job cleared so the project can settle back to the working dependency set, or (b) guidance on the supported way to reconcile the FlutterFlow-managed mime_type 1.0.0 pin with the library's ^1.0.1 requirement (e.g. raising the managed pin, or a sanctioned project-level override).
This matches the wedged-resolver pattern in #6331.
Can we access your project?
Current Behavior
The "Update dependencies to the latest version" operation is stuck on an endless spinner and never completes. Analyzer Status shows "Pub get failed."
The spinner persists across full project close/reopen, app restart, and reverting to earlier snapshots — including snapshots from before the conflict was introduced. Because reverting project state does not clear it, this appears to be a wedged platform-side resolution job, not a project-state issue. This matches the pattern in #6331.
Root cause of the underlying conflict, from the analyzer error: the installed FlutterFlow Library "ElevenLabs Conversational AI Library" (v1.2.0) depends on mime_type ^1.0.1, while the project's FlutterFlow-managed Pub Dependencies pin mime_type at exactly 1.0.0. These are unsatisfiable together, so version solving fails. The mime_type 1.0.0 entry is in the FlutterFlow-managed Pub Dependencies list (not Custom Pub Dependencies) and is not user-editable.
Exact analyzer message:
Because the_six_pages depends on elevenlabs_conversational2_x2dkep from path which depends on mime_type ^1.0.1, mime_type ^1.0.1 is required. So, because the_six_pages depends on mime_type 1.0.0, version solving failed. Failed to update packages.
The project was analyzer-green earlier today. The conflict appeared immediately after clicking "Update dependencies to the latest version" during a Firebase config regeneration. The library version did not change (it has been 1.2.0 throughout) — the update operation appears to have bumped a transitive dependency to a release that now requires mime_type ^1.0.1, introducing the conflict and then wedging the resolution job.
Expected Behavior
flutter pub get resolves successfully and the project returns to a buildable, analyzer-green state, as it was earlier today before "Update dependencies to the latest version" was clicked.
Specifically: a compatible dependency set provably exists (the project was green with library v1.2.0 and mime_type 1.0.0 coexisting), so the resolver should be able to settle back to that working set rather than remaining wedged on an unsatisfiable upgrade target.
Ideally, the FlutterFlow-managed mime_type pin would be reconciled with the library's ^1.0.1 requirement — either by raising the managed pin to a version that satisfies ^1.0.1, or by advising the supported way to override it at the project level.
Steps to Reproduce
Have a FlutterFlow project that imports the Marketplace library "ElevenLabs Conversational AI Library" v1.2.0 (Marketplace item rwPaVMENBqTorJiznewx, package elevenlabs_conversational2_x2dkep), which declares a dependency on mime_type ^1.0.1.
Confirm the project is analyzer-green in this state (it was, as of earlier today).
Trigger a dependency re-resolution — in this case, regenerate Firebase config files (Settings → Firebase → Regenerate Config Files), then click "Update dependencies to the latest version."
Observe the analyzer error: version solving fails because the FlutterFlow-managed Pub Dependency mime_type 1.0.0 cannot satisfy the library's ^1.0.1 requirement.
Observe that the "Update dependencies to the latest version" spinner then runs indefinitely and never resolves.
Confirm the spinner persists after: full project close and reopen; app/browser restart; and reverting to earlier snapshots (including pre-conflict snapshots). The wedged state does not clear through any user-available action.
Reproducible from Blank
Bug Report Code (Required)
IT5fz8r13ItPxOEE+KX6cfkwmioXQ1M7ULgriO0bEAgbIrnqP7AUPs/7N1BJYteFT2xcJWH/ingJzPTTv9ieUcc4BxCuGbY6wq9XdwvyLUyuRr6lPoeBPHFQRN5TGm3C1qWjuhV7A/NzWFllwzumJOeRY3PUHb7vCm07O/mXMpPJ+UKbGQ22VRcw7zcADmreTI5ODEz25eKMrop5yfj/0w==
Visual documentation
[
](url)
Environment
Additional Information
That's a real and reasonable fear, so let's write this field to do two jobs: convey genuine impact (which raises priority) and preempt the "just remove the library" non-answer you're worried about. The way to prevent that answer is to make clear, in their own technical terms, that a compatible resolution provably exists — so the correct fix is reconciling the pin, not abandoning the integration.
Here's what to paste:
This is blocking active pre-launch development on a project in TestFlight and Google Play closed testing. The voice feature built on this library is a core part of the app, and the entire backend integration (token endpoint, WebRTC session auth) is already complete and working — the only blocker is this dependency-resolution wedge.
I want to flag one thing to help triage: a compatible resolution provably exists. This exact project was analyzer-green earlier today with library v1.2.0 and mime_type 1.0.0 coexisting. The conflict only appeared after "Update dependencies to the latest version" pulled a transitive dependency up to a release requiring mime_type ^1.0.1. So the library and the managed pin are not fundamentally incompatible — the working set existed and was stable until the upgrade churn.
For that reason, removing or downgrading the library is not the resolution I'm looking for, and shouldn't be necessary. What I need is either (a) the wedged resolution job cleared so the project can settle back to the working dependency set, or (b) guidance on the supported way to reconcile the FlutterFlow-managed mime_type 1.0.0 pin with the library's ^1.0.1 requirement (e.g. raising the managed pin, or a sanctioned project-level override).
This matches the wedged-resolver pattern in #6331.