snapcore
many: consolidate prompting errors and add prompting error kinds
Rather than each prompting-related package defining and using their own error types, define all named errors in the interfaces/prompting package, and use them from elsewhere. This requires some adjustments to error messages.
Additionally, add corresponding error kinds for all errors which can occur from API requests and are expected to be handled in a particular way by clients. These include most of the errors defined in the prompting package, but omits some which are expected to be strictly internal errors.
Thus, clients can rely on error kinds rather than attempting to parse error messages from the API.
This is tracked internally by https://warthogs.atlassian.net/browse/SNAPDENG-31369
This will produce some churn with the prompting client, as error message parsing should be replaced with matching error kinds. Should discuss with @sminez for this, and also to check that the new error kinds cover all the use cases for the client, or if any should be added or consolidated.
Documentation changes are required for the new error kinds:
Keep https://forum.snapcraft.io/t/using-the-rest-api/18603#heading--errors in sync using doc/error-kinds.go.
I'll do this once we've done any necessary adjustments to the new error kinds and the PR is ready to merge.
Should discuss with @sminez for this, and also to check that the new error kinds cover all the use cases for the client, or if any should be added or consolidated.
yes, we should definitely sync with him
After discussion with @sminez today, we have a new plan which reduces the number of required error kinds and groups invalid field errors into categories.
Four prompting-related error kinds:
- prompting not running
- prompt with ID not found
- rule with ID not found
- invalid field (in reply or rule creation/patch/etc.)
The Value for the invalid field error kind then has a map from field name to more information.
Each invalid field is invalid for one of three reasons:
- unsupported value (for outcome, lifespan, etc. which have a fixed set of options)
- In the metadata we can include both the value that was provided and the list of supported options
- parse error (if field does not have fixed set of options, but the provided value is malformed)
- validation error (if field was well-formed, but the state of the system caused it to be rejected because of e.g. conflicting rule, permissions not covering requested permissions, etc.)
In the metadata under the validation error we can then have the detailed information about why exactly the field was invalid. This is the information which is currently spread across dedicated error kinds, but we'll instead put it here.
- duration / timestamp in the past / negative
- duration given when lifespan is not timespan
- duration not given when lifespan is timespan
- custom path does not apply to requested path
- custom path conflict with existing rule
- reply permissions do not cover requested permissions
- etc.
Failures: ubuntu-focal-jammy google:ubuntu-20.04-64:tests/main/nvidia-files:535_server - known issue, not related to changes
