dynamodb: conditional check failed

[rjhornsby]

Cross-posted ~30 days ago to the discussion forums with no replies, escalating here to a possible bug.

Describe the bug
Vault 1.17.3 - 1.18.1 AWS dynamodb backend "Conditional check failed (count)" metric > 0.

AFAICT, this does not appear to be causing any functional issues with our vault cluster. Nothing I can find in the vault server logs suggests a problem.

To Reproduce
Steps to reproduce the behavior:

• Run vault server with dynamodb backend, otherwise standard/vanilla config (included below)
• Observe "Conditional check failed (count)" metrics for vault's dynamodb table

Expected behavior
It's unclear if the conditional check failure count metric > 0 is normal/expected. The count value seems fairly consistent over time.

Environment:

• Vault Server Version (retrieve with vault status): 1.18.1
• Vault CLI Version (retrieve with vault version): n/a
• Server Operating System/Architecture: Linux/x86

Vault server configuration file(s):

# Global
api_addr = "https://vault-mycorp.com:8200"
ui = true
disable_mlock = false

# listener
listener "tcp" {
  address = "0.0.0.0:8200"
  tls_disable = false
  tls_cert_file = "/etc/vault.d/mycorp.com.crt.pem"
  tls_key_file  = "/etc/vault.d/mycorp.com.key.pem"
  # https://stackoverflow.com/a/73222762
  # aws ALB does not support TLS 1.3 (yet?)
  tls_min_version = "tls12"

  # see https://developer.hashicorp.com/vault/docs/configuration/listener/tcp#tls_cipher_suites
  # and https://golang.org/src/crypto/tls/cipher_suites.go
  # for why tls is maxed out at 1.2 and why the cipher list used here was chosen
  tls_max_version = "tls12"
  tls_cipher_suites = "_suite_list_"
}

plugin_directory = "/etc/vault.d/plugins"

# seal
seal "awskms" {
  region = "us-west-2"
  kms_key_id = "xxxx"
  access_key = "xxxx"
  secret_key = "xxxx"
}

# storage
storage "dynamodb" {
  ha_enabled = true
  region = "us-west-2"
  table = "vault-myorg"
}

telemetry {
  dogstatsd_addr = "127.0.0.1:8125"
}

Additional context
This "issue" is not new per-se, it was present in 1.17.3 or possibly earlier versions. We noticed it around 1.17.3, but it continues after upgrading to 1.18.1 a few days ago.