Configuring plugin fails with unhelpful message if api_addr is not set

[nirvana-msu]

If api_addr is not set in Vault config, then an error is thrown when trying to configure plugin:

vault write /github/config app_id=<app_id> prv_key=@<private_key_file>

vault[238597]: 2022-09-08T23:08:58.339Z [ERROR] secrets.vault-plugin-secrets-github.vault-plugin-secrets-github_71c98872.vault-plugin-secrets-github.vault-plugin-secrets-github: plugin tls init: error="no vault api_addr found" timestamp=2022-09-08T23:08:58.339Z
vault[238597]: 2022-09-08T23:08:58.352Z [ERROR] rollback: error rolling back: path=github/
vault[238597]:   error=
vault[238597]:   | Unrecognized remote plugin message:
vault[238597]:   |
vault[238597]:   | This usually means that the plugin is either invalid or simply
vault[238597]:   | needs to be recompiled to support the latest protocol.
vault[238597]:
vault[238597]: 2022-09-08T23:08:58.352Z [INFO]  secrets.vault-plugin-secrets-github.vault-plugin-secrets-github_71c98872.vault-plugin-secrets-github: plugin process exited: path=/etc/vault/vault_plugins/vault-plugin-secrets-github pid=239887

Note the error "no vault api_addr found" above.

At first I thought api_addr was only needed with cluster backends. Took me some time before I found a message in the docs that This value is also used for plugin backends.

Perhaps not so much an issue with this plugin, but what's rather confusing is that Vault itself works just fine without this parameter (with file backend). In particular, I can see a log message that actually suggests it implies the value (presumably from bind address):

vault[179732]: 2022-09-07T16:47:20.328+0200 [WARN]  no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set

A second issue was that API call itself returned an unhelpful message:

Error writing data to github/config: Error making API request.

URL: PUT https://127.0.0.1:8200/v1/github/config
Code: 500. Errors:

* 1 error occurred:
        * internal error

Log messages above suggest there may have been a change in the plugin protocol that caused the error to fail propagating?