Handle more buildplanner errors #3547
Conversation
MDrakos
commented
Oct 17, 2024
•
MDrakos
commented
 DX-2821 Handle Buildplanner errors with user facing messages
|
This reverts commit b74438b.
| } | ||
| // ValidationError represents a validation error that occurred during planning. | ||
| // Contains message and subErrors which is handled separately | ||
| type ValidationError struct{} |
There was a problem hiding this comment.
We now have multiple errors with SubErrors so I moved that to the common Error struct
|
I found that a lot of the errors we are currently handling wouldn't be very enriched by the extra fields. I also took the time in this PR to handle errors that we weren't before. |
There was a problem hiding this comment.
We should be using the rationalizer for this. These are already returning typed errors, which are at least to some level already rationalized. Adding localized errors underneath them feels inappropriate. We should only be marking input errors outside of rationalizers if there is a clear reason why rationalizing doesn't work there.
This reverts commit e401490.
|
Closing this PR and filed another story that I think will better address our buildplanner error handling. |
