Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: iOS connectivity_plus retains callbacks in multi-FlutterEngine apps

Chiusa
  • Qualcosa non va?
#3,958 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
dart, flutter, swift
Ambito
mobile

Direzione di ricerca

Inizia nell’implementazione iOS di connectivity_plus, concentrandoti su ConnectivityPlusPlugin, PathMonitorConnectivityProvider e sul ciclo di vita della registrazione dell’engine. Riproduci il ciclo di creazione, sottoscrizione, distacco e distruzione di più FlutterEngine descritto nell’issue. Il lavoro è completato quando ogni engine rilascia il proprio event sink e il proprio monitor di connettività durante il teardown, i callback non puntano più agli engine distaccati e gli altri engine continuano a monitorare normalmente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Platform

iOS, in applications that register connectivity_plus on more than one FlutterEngine (for example, a long-lived main engine plus short-lived secondary engines).

Plugin

connectivity_plus

Version

7.3.1

Flutter SDK
  • Flutter 3.35.7 / Dart 3.9.2: production crash observed in our multi-engine host.
Steps to reproduce
  1. Create a long-lived FlutterEngine and register connectivity_plus.
  2. Create a second, short-lived FlutterEngine and register the plugin there too.
  3. Subscribe to onConnectivityChanged on the secondary engine.
  4. Destroy or detach the secondary engine while a network callback is pending, then repeat the create/destroy cycle.
Actual behavior

The iOS plugin retains callback chains after an engine is no longer usable:

  • ConnectivityPlusPlugin -> ConnectivityProvider -> connectivityUpdateHandler -> ConnectivityPlusPlugin
  • PathMonitorConnectivityProvider -> NWPathMonitor -> pathUpdateHandler -> PathMonitorConnectivityProvider

The callbacks are assigned as bound method references, which retain their owners. The plugin is also not published through the registrar, so Flutter cannot invoke detachFromEngine(for:) when the engine is deallocated.

In a multi-engine application this leaves stale providers and network callbacks associated with short-lived engines. A later callback can attempt to deliver an EventChannel event after that engine has exited, causing:

Sending a message before the FlutterEngine has been run.

The retained callback graph also prevents timely release of the plugin/provider.

Expected behavior

Each FlutterEngine should own an independent plugin lifecycle. When an engine is detached or deallocated, its connectivity monitor and EventChannel sink should be released without affecting other engines, and no callback should target the detached engine.

Proposed fix
  1. Use weak captures for both callback edges.
  2. Publish the plugin instance with registrar.publish(instance).
  3. Implement detachFromEngine(for:) to clear the event sink and stop the engine-owned monitor.

This keeps normal connectivity monitoring unchanged while making teardown safe for multi-FlutterEngine hosts.

Code sample
final subscription =
    Connectivity().onConnectivityChanged.listen((_) {});

// In a host application, dispose the secondary FlutterEngine while this
// subscription is active, then create another secondary engine.
Logs
Fatal Exception: NSInternalInconsistencyException
Sending a message before the FlutterEngine has been run.

-[FlutterEngine sendOnChannel:message:binaryReply:]
FlutterBinaryMessengerRelay
SetStreamHandlerMessageHandlerOnChannel
SwiftConnectivityPlusPlugin.connectivityUpdateHandler
Lingua principale
Dart
Stelle
1.9k
Fork
1.3k
Merge medio
6g 16h
PR unite (30g)
16

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di fluttercommunity/plus_plugins

Tutte le issue di fluttercommunity/plus_plugins

Issue simili

Altre issue su Dart

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.