-
Notifications
You must be signed in to change notification settings - Fork 5
Closed
Labels
developmentStandard developmentStandard development
Description
Specification
Similarly, both handlers return a string if an error happens. This is not ideal. Instead, an error object like SuccessOrErrorMessage can instead be returned, and the error string can be built by the client themselves. This is done to an extent by VaultsSecretsMkdir (see Additional context), but that approach is still incorrect, as VaultOps returns an error object instead of throwing an error. All VaultOps operations should throw an error, which should be handled and converted as necessary by the handler itself.
Additional context
- Blocked by Polykey#821
- This is done to an extent by VaultsSecretsMkdir
// VaultsSecretsMkdir
yield await vaultManager.withVaults(
[vaultId],
async (vault) => {
return await vaultOps.mkdir(vault, dirName, {
recursive: metadata?.options?.recursive,
});
},
tran,
);
// vaultOps.mkdir()
try {
await vault.writeF(async (efs) => {
await efs.mkdir(dirPath, fileOptions);
logger?.info(`Created secret directory at '${dirPath}'`);
});
return { type: 'success', success: true };
} catch (e) {
logger?.error(`Failed to create directory '${dirPath}'. Reason: ${e.code}`);
if (e.code === 'ENOENT' && !recursive) {
return {
type: 'error',
code: e.code,
reason: dirPath,
};
}
if (e.code === 'EEXIST') {
return {
type: 'error',
code: e.code,
reason: dirPath,
};
}
throw e;
}Tasks
- Return a proper SuccessOrErrorMessage from VaultsSecretsRemove and VaultsSecretsGet
- Update VaultOps.mkdir to throw errors rather than returning an error object
- Go through all the tests for them all and ensure everything is up to date
- Use fastcheck where possible to test these things out
Metadata
Metadata
Assignees
Labels
developmentStandard developmentStandard development