@chinmaygarde @eseidelGoogle

As a crash mitigation this seems OK. Ideally we'd have tests. We might also want to consider throwing exceptions or queuing.

@collinjackson this was showing up in Posse's app as random crashers when the Firebase Datastore plugin would attempt to deliver messages to Dart while the FlutterView was detached (generally on an idle wake where java was faster than the FlutterView, etc.)

@mravn-google you should be aware of this hole in the plugin architecture. Messages can attempt to send messages to detached (backgrounded, screen off, etc.) FlutterView's and previously they would just crash with a null pointer SIGSEGV. This changes that behavior to log, but the message is still lost.

FYI @lukef

Please add a test if possible.

Please file a bug to track replacing the log with an improvement to the protocol.

Is this issue Android only, or do we have the same problem on iOS?

This was a quick workaround for a crash in production apps. @jason-simmons's analysis of the underlying issue in at least one of the production apps:

The Firebase plugin registers for notifications about data changes, but it doesn't unregister when the associated instance of Flutter is destroyed. When a notification arrives via a cloud message, the plugin will try to notify the app by calling send() on the defunct FlutterView. FlutterView didn't guard against this, resulting in a segfault.

The current workaround will log a warning and then ignore an attempt to send a message to a Flutter engine that is no longer running. Later we will need a way to close the Firebase subscriptions that are no longer needed.

Thanks again for the quick turnaround.

@mravn-google I suspect we may be leaking firebase registrations everywhere, but we've only seen the crash reported on iOS. Unclear why.

iOS? This change is on the Android side.

Sorry, I meant "only reported on Android".