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

package(mongo) Do not break API to handle validation errors with internal errors #999

Merged
merged 3 commits into from
Nov 21, 2024

Conversation

leo-scalingo
Copy link
Contributor

Fixes #998

  • Add a changelog entry in CHANGELOG.md

@leo-scalingo leo-scalingo self-assigned this Nov 21, 2024
Copy link
Member

@EtienneM EtienneM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not convinced by this API. Shouldn't we just revert #552? I mean, from the calling method, it's feasible to distinguish between a validation error and an internal error, isn't it?

@leo-scalingo
Copy link
Contributor Author

I'm really not convinced by this API. Shouldn't we just revert #552? I mean, from the calling method, it's feasible to distinguish between a validation error and an internal error, isn't it?

I don't understand, currently we can' have a validation method which returns something else than a *errors.ValidationErrors, so it's just not possible to distinguish between a validation error and an internal error, because an internal error is not returnable.

My attempt here is to open to this possibility because indeed there are some simtuations in which a validation may fail because we can't access some data, or something internal is failing, with this PR it becomes possible without breaking the API. I thought it would be quite a elegant way to solve the initial problem which is indeed a problem.

@leo-scalingo
Copy link
Contributor Author

How would you handle this without breaking the API?

Copy link
Member

@EtienneM EtienneM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I didn't understood correctly at the first read.

I'm already approving despite the suggestions and the failing CI. I let you choose whether you want to take into account the suggestions or not.

After releasing this, I think it would be nice to send a message on team-tech so that all Go developers are aware of this change.

// Validate will be used if no ValidateWithInternalError is defined on a document
// It is not useful to have both defined on a document, only ValidationWithInternalError
// would be used in this case
Validate(ctx context.Context) *errors.ValidationErrors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: do we want to deprecate this method? In such case, we should document it IMO:

Suggested change
Validate(ctx context.Context) *errors.ValidationErrors
// Deprecated: ...
Validate(ctx context.Context) *errors.ValidationErrors

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to deprecate, it's just 2 ways to define validation, I think that keeping a simple signature for the comon case works well.

if err == ErrValidateNoInternalErrorFunc {
validationErrors = doc.Validate(ctx)
} else if err != nil {
return errors.Wrap(ctx, err, "fail to validate document")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick(non-blocking):

Suggested change
return errors.Wrap(ctx, err, "fail to validate document")
return errors.Wrap(ctx, err, "validate document")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack

Comment on lines 88 to 89
"collection": collectionName,
"doc_id": doc.getID().Hex(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: what do you think about adding these fields in the logger in the save function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack!

@leo-scalingo
Copy link
Contributor Author

I'm already approving despite the suggestions and the failing CI. I let you choose whether you want to take into account the suggestions or not.

I'll take t hem all into consideration :)

@leo-scalingo leo-scalingo force-pushed the fix/998/validation-internal-errors branch from 25833f8 to e800254 Compare November 21, 2024 14:19
@leo-scalingo leo-scalingo force-pushed the fix/998/validation-internal-errors branch from 3d3595f to ae3124d Compare November 21, 2024 14:40
@leo-scalingo leo-scalingo merged commit 2dad0ed into master Nov 21, 2024
4 checks passed
@leo-scalingo leo-scalingo deleted the fix/998/validation-internal-errors branch November 21, 2024 14:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

package(mongo) Do not break Validate() API in next release, extend current API instead
2 participants