The listSecrets function (soon to be renamed in #100) returns a [Text]. These strings can be either entry names or directory names.
Vault will add a / suffix to directory names, and Backend.Commands.getEntryOrDir relies on this behaviour to decide whether each of those strings is an entry name or a directory name.
However, this behavior is specific to the Vault backend. Other backends might not behave like this.
So we should hide this behavior behind listSecrets.
Instead of returning a [Text], it should return a new data structure DirectoryContents with two fields: directoryNames :: [PathSegment] and entryNames :: [PathSegment].
Also:
We should add a haddock to ListSecrets.
As part of this task, I think InvalidEntry could be moved from InternalCommandsError to VaultError.
We could also rename InvalidEntry to InvalidPathSegment, I think
Acceptance criteria
listSecrets returns an appropriate data structure that doesn't rely on backend-specific details.
Clarification and motivation
The
listSecretsfunction (soon to be renamed in #100) returns a[Text]. These strings can be either entry names or directory names.Vault will add a
/suffix to directory names, andBackend.Commands.getEntryOrDirrelies on this behaviour to decide whether each of those strings is an entry name or a directory name.However, this behavior is specific to the Vault backend. Other backends might not behave like this. So we should hide this behavior behind
listSecrets.Instead of returning a
[Text], it should return a new data structureDirectoryContentswith two fields:directoryNames :: [PathSegment]andentryNames :: [PathSegment].Also:
ListSecrets.InvalidEntrycould be moved fromInternalCommandsErrortoVaultError.InvalidEntrytoInvalidPathSegment, I thinkAcceptance criteria
listSecretsreturns an appropriate data structure that doesn't rely on backend-specific details.