google-api-go-client: Cannot deploy Cloud Run using API: badRequest INVALID_ARGUMENT (no further details provided)

Client

Run-v1: google.golang.org/api/run/v1

Describe Your Environment

JetBrains GoLand IDE
go 1.13.4
google.golang.org/api v0.15.0 (have also tried with google.golang.org/api v0.14.0, same result)
Google Cloud Run

Expected Behavior

Ability to deploy a new Cloud Run Service object using the golang library.

Actual Behavior

Attempting to deploy a new Cloud Run service returns a badRequest response, with status INVALID_ARGUMENT despite basing the Service model on an existing, manually created service using:

gcloud run services describe existing-service1 --format=json --project=MY_PROJECT --platform=managed

*** Click here for the code used to attempt the deployment ***

Error:

{
  "error": {
    "code": 400,
    "message": "The request has errors",
    "errors": [
      {
        "message": "The request has errors",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT"
  }
}

Happy to supply any further info if needed?

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 19 (6 by maintainers)

Most upvoted comments

Wow, that was not expected. Thanks for catching that.

We’ll track this internally and remove this special behavior (internal issue: 159834830)

steren on Jun 24, 2020

The Cloud Run API team will work on returning a better error message.

But I suggest we re-open this issue @jadekler

Users of the API are able to deploy to Cloud Run without issues (see this post which is using a hand written Go client for example)

The actual issue is very likely due to this library, which I guess does not generate the expected payload.

CC @JustinBeckwith

steren on Jun 17, 2020

Oh wow, looks like it works now thanks a lot @codyoss! Sorry about that, I’m pretty new to GCP maybe, but that explains why it’s returning a pretty generic error. I guess the only actionable thing would be to return an error specific to the endpoint being invalid, that would go a long way to pointing out the issue if it’s possible

tj on Jun 23, 2020

This is also confirmed by manually deploying the payload reported above, we get this error message returned in the status field:

The revision name must be prefixed by the name of the enclosing Service or Configuration with a trailing -

steren on Jun 17, 2020

in the JSON object reported above: I see that spec.template.name is set to test1. This is likely the culprit, because I think the revision name must be prefixed by the service name and -. Can you try leaving this field unset, or use test1-foo ?

steren on Jun 17, 2020