Repository navigation
Dart_PostCObject doesn't communicate why it fails #64488
Description
Description
When Dart_PostCObject returns false, an embedder can't tell why. Today it can fail for three different reasons:
- The message couldn't be serialized (
WriteApiMessagereturned nullptr). - The destination port doesn't exist (it was closed, or its isolate exited).
- The VM is shutting down (
PortMap::ports_ == nullptr).
Reasons 2 and 3 are normal when a reply comes back after its isolate is gone. Reason 1 is a bug in the embedder. Embedders want to handle these differently, ignoring the first two and aborting on the third, but the API returns the same bool for all three.
linked issues
Proposed fixes
- Make a new
Dart_PostCObjectthat returns an enum that represents the status instead of just a bool. - Add a new function
bool Dart_IsPortAlive(Dart_Port port_id)
Activity
Removed crash when responding on a dead port. (flutter#193827)
biggs0125 commentedon Oct 7, 2026
We can add a variant of
Dart_PostCObjectthat indicates the status reason.But we cannot implement
Dart_IsPortAliveas this is a synchronous query that may leak details about the port being asked about.How frequently are people running into this? Not sure how much bandwidth we have for this right now.
gaaclarke commentedon Oct 7, 2026
The reproduction is killing an engine that is in the process of receiving a platform channel response. I've made it not a crash in flutter and instead issued a log.
I think we would like to have it crash if the response fails to send and we aren't in a situation where we are shutting down the engine. I'm particularly concerned about situations where messages are not delivered since that can cause deadlocks in workflows. Maybe overly concerned.