Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task: Improve the task result by making the result message and error simpler #454

Open
1 task done
kairoaraujo opened this issue Feb 9, 2024 · 1 comment
Open
1 task done
Assignees

Comments

@kairoaraujo
Copy link
Member

What is the task about?

We can do the task result from the Worker better, see this discussion below.

Only mandate task results with message field for SUCCESS, ERROR, FAILURE state responses, and do not add them if they are missing in any of the other state responses.
Consolidate message and error fields for ERROR and FAILURE.
For ERROR the message could be a combination of what's currently in both fields, and error could be omitted.
For FAILURE the message could be the exception message, and error could be omitted or show the exception type.

Source: repository-service-tuf/repository-service-tuf-api#524 (comment)

The changes were made in the RSTUF API and require 'enforcement' in the RSTUF Worker.

Parent feature

No response

References

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@KAUTH
Copy link
Collaborator

KAUTH commented Apr 9, 2024

@kairoaraujo For this task I think we should consider removing the error field in general (we can set it to None and gradually remove it from the other RSTUF component if it's being used or remove it at once now if it's not being used).

Since the idea is to merge the error and message fields, IMO it doesn't make sense to keep them both in their current format.
If message was a human-readable error message (as it is now) and error was a single string value denoting the error type, then it would be logical to keep both fields. However, I think that would be a bigger change since we would need to standardize the error code strings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

2 participants