IssueTracker

This will create a public issue which anybody can view and comment on.

Please provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible please provide a summary of what steps or workarounds you have already tried, and any docs or articles you found (un)helpful.

Problem you have encountered:

I'm using the cloud task HTTP API to create a task with a specified name. If that task has existed too recently, there is an (expected) error stating that another task with that name is too recent.

HOWEVER

The audit log generated when a task has existed too recently misleadingly says that the error is NOT_FOUND, instead of ALREADY_EXISTS as is returned by the http endpoint.

What you expected to happen:

The error code in the audit logs should match the error code that's returned from the HTTP call. It should be ALREADY_EXISTS, not NOT_FOUND.

Steps to reproduce:

0. Turn on logging for the queue you're about to work with.
1. Use the cloud tasks API page to create a cloud task in any queue, specifying the name of the task, e.g.,

parent: projects/my-project/locations/us-central1/queues/my-queue request body:

{
  "task": {
    "name": "projects/my-project/locations/us-central1/queues/my-queue/tasks/task-123",
    "httpRequest": {
      "httpMethod": "GET",
      "url": "https://example.com"
    }
  }
}

2. Click the "Execute" button and observe that the task is created successfully (200 response)
3. Without changing anything, click the "Execute" button again, and observe that there is a 409 Conflict error, saying "The task cannot be created because a task with this name existed too recently" (this is fine and expected behavior)
4. Go to cloud logging and find the associated TaskCreation log, e.g., you can search for the queue name:

jsonPayload.task="projects/my-project/locations/us-central1/queues/my-queue/tasks/task-123"

5. Observe: the jsonPayload.taskCreationLog.status is NOT_FOUND. Expect: it should be ALREADY_EXISTS since that is the error message returned by the http endpoint.

We spent a long time trying to determine if the queue had gone missing or something else was misconfigured when we saw this error status in our audit logs.

Other information (workarounds you have tried, documentation consulted, etc):