Skip to content

feat: Add root-isolate predicate and pin secondary-isolate plugin behaviour (#5302) - #7270

Draft
cadivus wants to merge 1 commit into
feat/isolate-bootstrap-helperfrom
feat/isolate-category-guardrails
Draft

feat: Add root-isolate predicate and pin secondary-isolate plugin behaviour (#5302)#7270
cadivus wants to merge 1 commit into
feat/isolate-bootstrap-helperfrom
feat/isolate-category-guardrails

Conversation

@cadivus

@cadivus cadivus commented Aug 12, 2026

Copy link
Copy Markdown
Member

⚠️ Groundwork, not the guard — the guard could not go where the plan said. Stacked on #7269. No behaviour change: one new @internal getter, nothing here consumes it.

  • The guards cannot live at this layer. AmplifyCategory.addPlugin (amplify_core/lib/src/category/amplify_categories.dart:91-101) already catches AmplifyAlreadyConfiguredException and registers the plugin anyway, so nothing is left for amplify_flutter to observe. I wrote the guard in hybrid_impl.dart, proved it dead with a test, and reverted it. amplify_core is Flutter-free and cannot tell which isolate it is on, so each native-backed plugin guards in its own native call path instead — see feat(datastore): Refuse configure from a secondary isolate (#5302) #7271 (DataStore) and feat(auth): Refuse addPlugin from a secondary isolate without a messenger (#5302) #7272 (Auth).
  • Adds amplifyIsInRootIsolate — true for an app main isolate and a headless FlutterEngine, false only inside Isolate.spawn. Cannot false-positive on the root isolate.
  • Pins the category-layer swallow described above in CI, plus: a pure-Dart plugin still configures fine in a secondary isolate, and the root isolate still tolerates an already-configured native SDK (hot-restart path). 15 tests, all in CI.
  • Deferred follow-up — push guard. Not in this stack. It needs an integration_test/ harness for the amplify_push_notifications_pinpoint example, an e2e_android leg (neither exists today), and a test-only native hook to invoke the background service and report amplifyIsInRootIsolate from inside the real headless engine. Native work with its own testing plan; the guard must not ship on static analysis alone.

@codecov-commenter

codecov-commenter commented Aug 12, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 41.58%. Comparing base (dd1b8fd) to head (16686a0).

Additional details and impacted files
@@                        Coverage Diff                        @@
##           feat/isolate-bootstrap-helper    #7270      +/-   ##
=================================================================
+ Coverage                          41.03%   41.58%   +0.54%     
=================================================================
  Files                                122      124       +2     
  Lines                               8285     8193      -92     
  Branches                            3607     3587      -20     
=================================================================
+ Hits                                3400     3407       +7     
+ Misses                              4885     4786      -99     
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

)

Groundwork for the #5302 category guardrails. No behaviour change: the only
production change is a new `@internal` getter, and nothing in this commit
consumes it.

- `amplifyIsInRootIsolate` in amplify_flutter: true for an app's main isolate
  and for a headless `FlutterEngine` entry point, false only inside
  `Isolate.spawn`. Built on `ServicesBinding.rootIsolateToken`, so it cannot
  false-positive on the root isolate.
- Pins the behaviour of the layer above the guards: `AmplifyCategory.addPlugin`
  (amplify_core/lib/src/category/amplify_categories.dart:91-101) swallows
  `AmplifyAlreadyConfiguredException` and registers the plugin anyway, so
  nothing is left for amplify_flutter to observe.

That swallow is why the guards cannot live at this layer. `amplify_core` is
Flutter-free and cannot tell which isolate it is on, so each native-backed
plugin guards inside its own native call path instead. A guard in
`hybrid_impl.dart` was written, proven dead by test, and reverted.
@cadivus
cadivus force-pushed the feat/isolate-category-guardrails branch from 8636810 to 16686a0 Compare August 12, 2026 16:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants