vault kv put cli hangs/waits indefinitely when not enough memory available

[Xerkus]

Describe the bug
vault kv put does not error, print any messages or time out when not enough memory is available, effectively blocking indefinitely. This is probably more generic occurrence for vault cli and not specific here.

Discovered while running vault kv put from certbot deploy hook in docker container started by nomad task with 64mb memory limit:

  vault kv put "kv2/acme/certs/$cert_name" \
    "cert=@${RENEWED_LINEAGE}/cert.pem" \
    "chain=@${RENEWED_LINEAGE}/chain.pem" \
    "fullchain=@${RENEWED_LINEAGE}/fullchain.pem" \
    "privkey=@${RENEWED_LINEAGE}/privkey.pem"

I did not get to experiment more with it yet but I am certain it did not get to the request context, hence normal timeout wouldn't be applied yet.

To Reproduce
TBD

Expected behavior
Probably an error trying to allocate memory or at least stderr message

Environment:

• Vault CLI Version: 1.9.3
• Server Operating System/Architecture: Fedora Cloud 35 amd64 (cgroups v2)
• Nomad agent: 1.2.5
• Docker: 20.10.12

Vault server configuration file(s):

# Paste your Vault config here.
# Be sure to scrub any sensitive values

Additional context
docker stats reported memory as
hanging: 55.6MiB / 64MiB
working: 73.68MiB / 100MiB

Not sure if helpful. When chasing certbot old pipe issue I've seen one of those two outputs from lsof:

68	/usr/local/bin/vault	/dev/pts/0
68	/usr/local/bin/vault	pipe:[3509054]
68	/usr/local/bin/vault	pipe:[3509055]

76	/usr/local/bin/vault	/dev/pts/0
76	/usr/local/bin/vault	pipe:[3511922]
76	/usr/local/bin/vault	pipe:[3511923]
76	/usr/local/bin/vault	anon_inode:[eventpoll]
76	/usr/local/bin/vault	pipe:[3511088]
76	/usr/local/bin/vault	pipe:[3511088]

[VinnyHC]

We discussed this request in our engineering team sync today. While the request is reasonable, we'd like to take some time to dig into the potential implementation details. As a result, it may take longer for a final decision to be made, whether it's that we accept a PR from the community, or handle the work internally as part of an upcoming release, or if the decision ends up being that it would be safer (from a functionality, compatibility, or security point of view) not to take this request on. We will link this request internally and work with product and engineering leaders to come to a decision. Thanks in advance for your patience!