Getting '410 Gone: editDeleted' errors on CLI

[mopewa]

We have two flavors that build separate apps (with different package names). On the CLI we assemble and bundle the two flavors and also execute publishFlavor1ReleaseBundle publishFlavor2ReleaseBundle to publish them to the play store. However, this fails with error:

Caused by: com.google.api.client.googleapis.json.GoogleJsonResponseException: 410 Gone
{
  "code" : 410,
  "errors" : [ {
    "domain" : "androidpublisher",
    "message" : "This Edit has been deleted.",
    "reason" : "editDeleted"
  } ],
  "message" : "This Edit has been deleted."
}

Our current build file uses this setup:

play {
    serviceAccountCredentials = playCredentialsFile
    track = "internal"
    defaultToAppBundles = true
    resolutionStrategy = "auto"
    outputProcessor { // this: ApkVariantOutput
        versionNameOverride = versionNameStr + "$versionCode"
    }
}

After reading #629 and seeing the issue might be caused by the tasks running in parallel, I tried using the workaround suggested there (having publish tasks write to output file) and it seems to have helped a bit but is still happening.

Versions

• Gradle Play Publisher: 2.7.5
• Gradle Wrapper: 6.2
• Android Gradle Plugin: 3.6.3

[SUPERCILEX]

Hmmm, I wonder if it might be related to #777 somehow. Can you share a build scan or look for tasks named generateEditFor*. These should have two different package names. Somehow, one of your publishing tasks is trying to use the other's edit which won't work since they'll race until one of them finishes and then fails the other.

[mopewa]

@SUPERCILEX just checked and there are two separate generateEditFor.. tasks with different package names. One thing that I didn't mention and I don't know if it's relevant is that one package name is a substring of the other (generateEditForComDotApplicationDotId and generateEditForComDotApplicationDotIdDotFlavor2). The way we've set this up is having a defaultConfig applicationId, then appending to it for flavor 2.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SUPERCILEX]

Whoops. I've been intending to investigate this, but I need to create another fake app listing which I haven't gotten around to yet.

[SUPERCILEX]

Does this happen 100% of the time? I tried publishing two apps and it worked just fine:

    flavorDimensions("a")
    productFlavors {
        register("old") {
            dimension = "a"
            applicationId = "com.supercilex.test"
        }

        register("new") {
            dimension = "a"
            applicationId = "com.supercilex.test2"
        }
    }

[SUPERCILEX]

I think it has something to do with how the applicationId is configured, so it would be great if you could show me the relevant parts of your build file.

[mopewa]

android {
  defaultConfig {
    applicationId "com.medium.reader"
  }
}

flavorDimensions "default"

productFlavors {
  external {
  }

  hatch {
    applicationId android.defaultConfig.applicationId + ".hatch"
  }

  dev {
    applicationId android.defaultConfig.applicationId + ".dev"
  }
}

play {
  serviceAccountCredentials = playCredentialsFile
  track = "internal"
  defaultToAppBundles = true
  resolutionStrategy = "auto"
  outputProcessor { // this: ApkVariantOutput
    versionNameOverride = versionNameStr + "$versionCode"
  }
}

Some things I tried while debugging: explicitly defining an applicationId for the external product flavor (didn't work), having the publish tasks write to the same folder to avoid them running in parallel (didn't work), removing publishHatchReleaseBundle from the gradle command we were running on the CI (this also didn't work until I also added some logic to disable the generateEditForComDotMediumDotReaderDotHatch task in our build file). I eventually found a workaround that let us publish both flavors: we run the commands as separate steps (so instead of running one gradle command to test, build, bundle, and publish both flavors, we now build them first then run two additional commands to publish each flavor from the created artifacts)

The error wasn't happening 100% of the time, we would occasionally have one work (maybe ~1 in 10).

[SUPERCILEX]

Oh, I think I might know what's going on. Does your CI system run multiple builds in parallel? Or are other people on your team running release builds with those play credentials? Basically, anytime generateEditFor... is run, any previous edits for that package name will be deleted (unfortunately, that's how the API works and there's no read-only mode). Since you have resolutionStrategy = "auto", anytime someone runs a release build for any reason, a new edit will be generated to get the latest version code. So if your CI system has multiple steps each running a release build or if someone runs a release build while the CI system is going, those edits will be wiped out. My guess is that your new solution works because the time needed to upload the bundle is very small compared to the build CI step which would create an edit sometime near the start of the build.

The solution would be to disable GPP or just auto resolution everywhere except for the CI step that runs publishing.

[mopewa]

Does your CI system run multiple builds in parallel?

We run the release builds for the different flavors in parallel. Is that what you mean? The generateEditFor... tasks that would be run in a given build have different package names though so I wouldn't think this would apply.

Otherwise, we don't run multiple release builds of the same flavor in parallel. The CI is the only machine with the credentials to run release builds and the job runs every 2 hours (jobs take an hour to run so we never have 2 builds running at the same time).

[SUPERCILEX]

Dang, I really thought that was it. No, it's totally fine to do stuff for different packages in parallel. The API only restricts edits on a package name basis.

I guess all I can tell you are the invariants:

• The generate edit task must run once per package name before any publishing tasks run.
• The commit task must run once per package name after all publishing tasks have run.
• No other system can make modifications to the release/listing (including on the Play Console I believe) during the time interval between generating and commiting the edit.

Since I can't repro, there's not much I can do. 😞

[SUPERCILEX]

Closing as non-reproducible. If someone can send me a sample project that reproduces this bug, please open a new issue.