cc @matanlurey, as you were active on the original issue as well

I personally would not make this change - streams have been in usage for a long time at this point, and there is nothing prohibiting us from introducing additional stream (or any de-sugared API), regressing the experience all over again. In other words, perhaps this fixes 1 particular problem for a subset of users, but it doesn't fix the underlying problem and perhaps even obfuscates it from us.

I personally would not make this change - streams have been in usage for a long time at this point, and there is nothing prohibiting us from introducing additional stream (or any de-sugared API), regressing the experience all over again. In other words, perhaps this fixes 1 particular problem for a subset of users, but it doesn't fix the underlying problem and perhaps even obfuscates it from us.

I agree it doesn't fix the larger problem, I'm also trying to do that separately. But we currently crash on a number of device/api levels that we claim to support, due to 1 trivial stream use. You don't think it's worth converting that to a different syntax while we attempt to solve the larger problem?

You don't think it's worth converting that to a different syntax while we attempt to solve the larger problem?

IMO, no, given the history.

We added this API in May 2022 (2ad3e5b), or approaching 3 calendar years from today. We have a serious problem if we can have a bug for 3 years, not detect it, and not know how to detect it, and I would put resources towards that instead of a particular crash (of which there might be more we just don't know about).

In other words, solving this particular issue makes it no longer important to research further (and it goes to the bottom of the stack priority wise). If we are sure that won't happen (it almost always happens), then I'd say go for it with a TODO but you/Reid would know best and ultimately make the call.

We added this API in May 2022 (2ad3e5b), or approaching 3 calendar years from today. We have a serious problem if we can have a bug for 3 years, not detect it, and not know how to detect it, and I would put resources towards that instead of a particular crash (of which there might be more we just don't know about).

Agreed but also I think these require multiple different orders of magnitude of effort to solve, and aren't really substitutes for each other.

In other words, solving this particular issue makes it no longer important to research further (and it goes to the bottom of the stack priority wise). If we are sure that won't happen (it almost always happens), then I'd say go for it with a TODO but you/Reid would know best and ultimately make the call.

I agree this is a serious problem and should not drop to the bottom of the priority list just because 1 crash is fixed. The fact that it is serious is a large part of why I want to land a short term fix, though.

@reidbaker WDYT?

@gmackall do you have a reproduction case that we have confirmed is fixed by this change? Or is this a best guess given the crash logs?

@gmackall do you have a reproduction case that we have confirmed is fixed by this change? Or is this a best guess given the crash logs?

This is a best guess, but also a pretty certain guess. I'm trying to reproduce the issue but have been unable. I may need to get my hands on a physical pixel 7 with Android 13

@gmackall do you have a reproduction case that we have confirmed is fixed by this change? Or is this a best guess given the crash logs?

This is a best guess, but also a pretty certain guess. I'm trying to reproduce the issue but have been unable. I may need to get my hands on a physical pixel 7 with Android 13

Ok my thought is let this pr sit. Matan is correct that this usage is 3 years old which makes the fix less urgent. My worry is that the regression was not using this code but something else about our setup or tooling that happened more recently. If/when we get a reproduction case that will let us prove when the issue started.

We would land this change if we are not able to find a way to reproduce that way we are not dropping the priority of finding the root cause or how to protect against it.

In your attempts I would suggest creating an AAB then turning that into an apk. That is one of the differences between play store uploads and what we test.

My worry is that the regression was not using this code but something else about our setup or tooling that happened more recently. If/when we get a reproduction case that will let us prove when the issue started.

The reporter of #160945 is potentially experiencing it as a regression, but there are many others who have reported it further back (going back to 2023).
#141949
#148109

I am doubtful this is a new issue in 3.27

@gmackall What it the plan with this pr?

from android triage: @johnmccutchan Would you rather land this without an investigation into the root cause or hold until the investigation is complete?

autosubmit label was removed for flutter/flutter/162024, because - The status or check suite Linux plugin_test has failed. Please fix the issues identified (or deflake) before re-applying this label.

autosubmit label was removed for flutter/flutter/162024, because - The status or check suite Google testing has failed. Please fix the issues identified (or deflake) before re-applying this label.