Gradle-play-publisher: FAILED_PRECONDITION when running publish*Bundle

[mochadwi]

Describe the bug

{

 "code" : 400,

 "errors" : [ {

 "domain" : "global",

 "message" : "This Edit has been deleted.",

 "reason" : "failedPrecondition"

 } ],

 "message" : "This Edit has been deleted.",

 "status" : "FAILED_PRECONDITION"

}

How To Reproduce

Versions

• Gradle Play Publisher: 2.8.0
• Gradle Wrapper: 6.5.1
• Android Gradle Plugin: 4.0.1

Tasks executed

What tasks did you run?

publish{BuildVariant}Bundle

Expected behavior

Success publishing

Additional context (if a crash, provide stack trace)

Add any other context about the problem here. If this bug is a crash, run the task with
--stacktrace to get the full context.

[SUPERCILEX]

Can you try on v3.0? And does this happen all the time? I've gotten reports like this before, but couldn't figure it out.

[ForceTower]

I get this error when I start a publish task when another is already running, for example.
The task: "generateEditForComDotCompanyDotApplication" happens really early compared to when the app is actually is going to be uploaded to google play, if another task on your CI execute the task "generateEditForComDotCompanyDotApplication", when it actually starts to upload the app, the edit would be deleted.

I don't know if this is possible, but if we could postpone the task "generateEditFor" to run after the aab/apks are built or to a later stage, this would happen less frequently.

[ForceTower]

I did something like this in my gradle file:

def generateEdit = tasks.findByName('generateEditForComDotExampleDotApp')
if (generateEdit != null) {
   generateEdit.mustRunAfter(':app:bundleRelease')
}

I'm not a gradle person, so this is probably not the best way to do this.

[SUPERCILEX]

Ah yeah, it's expected behavior for the edit to become invalid if someone else concurrently makes another edit. Sadly, that's a limitation of the publishing API: you can only have one active edit at a time. I don't think Gradle has a way to give priority hints. Does your hack work? bundleRelease should indirectly depend on generating the edit, so I feel like Gradle should crash.

[ForceTower]

Yes, the hack works, the generateEdit task runs after the aab is signed.

[SUPERCILEX]

Huh, I'll look into it then since creating a tighter bound on when the edit is created would be nice.

[mochadwi]

Really apologize guys, yes it's due to concurrent running task

After a while debugging this, yes the culprit is my mirror repository

consider this use case:

repo A & repo B (mirroring repo A), I'm pushing changes to repo A (triggered a CI pipeline to runs Triple-T task) thus the repo B also triggered as well

concurrent task (publishing) happened at the same time, repo B finishing the task first, then in repo A, the above error occurred

Turning off the mirroring repository in my case, fix my issue.

[mochadwi]

Huh, I'll look into it then since creating a tighter bound on when the edit is created would be nice.

Thanks for looking into this issue, anyway, should I close this issue? because that's a rare case for us to runs Triple-T task in concurrent cmiiw @SUPERCILEX

[ForceTower]

I believe that this is not a bug since it is intended behavior, but it's a nice feature request (postpone the generateEdit task to a later stage).

Also, according to what @SUPERCILEX said, ppl do run into this sometimes, maybe the solution is to just add a topic into the readme explaining that concurrent builds will cause one of them to fail.

[jleidgens]

for me the generateEditFor and commitEditFor tasks are run even if I only run the lint task.

Shouldn't this task only be triggered if an upload should be performed?
Because a lot of our build tasks run in parallel I get the same answer from the Play Store on every build.

[SUPERCILEX]

If you use auto resolution, an edit is needed to get the latest version codes.

[jleidgens]

Ah ok that explains why the problem is gone now.
Still why is this needed? I run a Lint task that only creates a XML report about code metrics.
Nothing that should trigger any job related to uploading. Is the auto resolution strategy changing app things during the build?

[ForceTower]

The default android lint task performs kind of a release build.

I don't use auto resolution, but I assume it is fetching the version code from play store to set the version code of the local release build.

[SUPERCILEX]

Yup, that's correct.

[SUPERCILEX]

@me maybe turn the generator task into a build service? https://docs.gradle.org/current/userguide/build_services.html

[SUPERCILEX]

The generate edit task is no more. :) I moved that logic to a build service which means an edit will be generated by the first task that needs it.

Note that these changes still won't help much when using auto resolution since an edit is needed to get the latest version codes early on in the build.