A bit of more information while I was looking to recover the task, Firestore only has the task for that commit with attempts 3 appended to the task entry in the datastore:

Nothing appended beyond that:

And in datastore it tracked the last run as the third failed attempt but was left as "In progress" (The screenshot shows succeeded as I had recovered it based on the newest run):

But you can see in the datastore that it is tracking the current number of attempts which shows it at 15.

Seems this is due to missing logic to handle tag current_attempt when rerunning via checkrun Re-run from GitHub UI for post-submit checkruns. https://github.com/flutter/cocoon/blob/main/app_dart/lib/src/service/luci_build_service.dart#L413

When rerunning from GitHub UI, it reset the current_attempt to 1: https://github.com/flutter/cocoon/blob/main/app_dart/lib/src/service/luci_build_service.dart#L616, which causes confusion on Firestore side.

This happened again here:

FWIW, the GitHub UI was the only UI to manage tasks in flutter/packages for many years, so trying to retrain everyone to never use that UI—especially when we still have the release task that can only be run/re-run from there—is going to be non-trivial. If we could make it work instead, that would be helpful.

@stuartmorgan nah I don't think this is a matter of retraining but just a bug on an edge case caused by a migration to a new datastore.

especially when we still have the release task that can only be run/re-run from there

This is peculiar, are you saying you are running release tasks from the github UI during presubmit? Can you add more context here?

I don't think this is a matter of retraining

I was referring to this comment in an issue dup'd to this one.

especially when we still have the release task that can only be run/re-run from there

This is peculiar, are you saying you are running release tasks from the github UI during presubmit? Can you add more context here?

No, I'm saying that the post-submit GitHub Actions task called release, which is responsible for actually publishing all of the packages in flutter/packages and is thus a critical part of our CI and gardening responsibilities, is only visible—and thus re-runnable—in the GitHub UI, not in the Flutter dashboard.

@stuartmorgan okay, thanks for clarifying.

No, I'm saying that the post-submit GitHub Actions task called release, which is responsible for actually publishing all of the packages in flutter/packages and is thus a critical part of our CI and gardening responsibilities, is only visible—and thus re-runnable—in the GitHub UI, not in the Flutter dashboard.

The rerun I referred to in #147033 (comment) was for LUCI (postsubmit) check run only. The GitHub action will not be affected and can be rerun as usual.

To be clear, the the LUCI check run (rerun) connects to cocoon backend to reschedule/update new builds, and is experiencing some issues. These issues can be workaround by calling the cocoon reset-prod-task API directly.

Anyway, I will give flutter/cocoon#3675 a high priority this week for a fix.

The rerun I referred to in #147033 (comment) was for LUCI (postsubmit) check run only. The GitHub action will not be affected and can be rerun as usual.

I understand that, but what I was saying is that everyone on the ecosystem gardener rotation:

• has muscle memory to retry failing post-submits from the GitHub UI, because it's how everything worked in that tree for many years, and
• still has to interact with that UI when there are failures (because failures in any post-submit test will cause release to fail, by design, and so release has to be re-run with other tests).

The combination of those two things makes it harder in practice to stop using it for LUCI tests than it is in theory.