Context Canceled Error on MYSQL mounts with Raft backend

Vault
1

Summary of issue

We are seeing requests that always succeed otherwise say context canceled when read operations are made on mysql mounts that results in users seeing a 504 context deadline exceeded message.

Questions

  • I was wondering if there are logs specifically for the integrated storage backend that I can find or configure somehow.

  • I was also curious if anyone had seen something like this before. Specifically the context canceled on the integrated storage backend.

The user sees the following:

Error reading {path}: context deadline exceeded

I am pasting an example log from vault below.

{
    "time": "2022-01-26T16:00:13.970352017Z",
    "type": "response",
    "auth": {
        "client_token": redacted,
        "accessor": redacted,
        "display_name": redacted,
        "policies": redacted,
        "token_policies": redacted,
        "metadata": {
            "username": redacted
        },
        "entity_id": redacted,
        "token_type": "service",
        "token_ttl": 2764800,
        "token_issue_time": "2022-01-26T15:43:40Z"
    },
    "request": {
        "id": redacted,
        "operation": "read",
        "mount_type": "mysql",
        "client_token": redacted,
        "client_token_accessor": redacted,
        "namespace": {
            "id": "root"
        },
        "path": redacted,
        "remote_address": redacted
    },
    "response": {
        "mount_type": "mysql"
    },
    "error": "1 error occurred:\n\t* context canceled\n\n"
}

Existing but seemingly unrelated information on context deadline succeeded

There is information about this happening: with when communication is made to a consul backend: Context Deadline Succeeded, but we are using integrated storage so it does not make sense that there would be connection or firewall issues.

2

Usually means “timedout”.

3

Sorry I was not clear. I was specifically referring to the context canceled on the integrated storage backend. Thanks for the response though.