The WAL rollback process for plugins is a way to have plugins cleanup external state from any failed requests. The intention is that, whenever a request comes in, the plugin is responsible for writing to framework.PutWAL() with some data, and then end a request by calling framework.DeleteWAL() to delete the data. If the request fails partway through, then DeleteWAL never gets called.
This PR makes framework.WALPrefix to be a local path so that performance secondaries wouldn't end up with the WAL data getting replicated.
WAL logs before the change:
2023-10-13T11:20:30.150-0700 [DEBUG] perf-pri.core0.secrets.local-azure.local-azure_ebf06d55.local-azure.vault-plugin-secrets-azure: rolling back SP: appID=b345ef81-8a2XXXXXX-82458841eb appObjID=19XX4866-XXX-4a6e-85dd-32ec2cXX480 timestamp=2023-10-13T11:20:30.150-0700
2023-10-13T11:20:31.376-0700 [DEBUG] perf-sec.core0.secrets.local-azure.local-azure_ebf06d55.local-azure.vault-plugin-secrets-azure: rolling back SP: appID=b345ef81-XXXX-ac82458841eb appObjID=19d64866-XXXX-85dd-32ec2c175480 timestamp=2023-10-13T11:20:31.376-0700
After the change:
2023-10-13T11:38:51.541-0700 [DEBUG] perf-pri.core0.secrets.local-azure.local-azure_0ec36706.local-azure.vault-plugin-secrets-azure: rolling back SP: appID=29eXXXX4f7-6ae3bXX39b appObjID=a93391d2XXXX31bcf29XXb9 timestamp=2023-10-13T11:38:51.540-0700
The WAL rollback process for plugins is a way to have plugins cleanup external state from any failed requests. The intention is that, whenever a request comes in, the plugin is responsible for writing to
framework.PutWAL()
with some data, and then end a request by callingframework.DeleteWAL()
to delete the data. If the request fails partway through, thenDeleteWAL
never gets called. This PR makesframework.WALPrefix
to be a local path so that performance secondaries wouldn't end up with the WAL data getting replicated.WAL logs before the change:
After the change:
Azure Auth PR: https://github.com/hashicorp/vault-plugin-auth-azure/pull/137