Update addError to give precedence to newly added schemas

[Avaq]

Type

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Description

HttpApiSchema.UnionUnify creates a union whose members are listed in the order of [...firstArgUnionMembers, ...secondArgUnionMembers]. When encoding a union, Schema will try each member in the order that they appear.

So the addError method on each of the HttpApi* classes, by passing the user-provided schema as a second argument, causes older schemas that encompass newer schemas to take precedence over the newer ones.

By flipping the argument order, users are now able to use addError with a schema that (partly) encompasses an older one, to override the encoding behaviour for values conforming to those schemas.

Related

• Related to Allow HttpApiEndpoint to override HttpApiDecodeError response #4751 (but doesn't fully fix it, as the default HttpApiDecodeError schema is still part of every HttpApi)
• Closes Customizing HttpApiDecodeError responses #5465

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8ac3f22

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Avaq]

I also have a WIP for adding a new .setDecodeError method to each of the HttpApi* classes, which would fix #5465, as well as make this ☝️ proposed "work around" for #5465 obsolete.

However, since this already addresses the bulk of the pain with a very small change, and since I think it's a good change overall, I'd say it's still worth considering.

[Avaq]

There's more sites where a union of the self.errorSchema is made with some the error schema of a unit being added. Like with addMiddleware. I'm not sure how we should treat those, but it may be worth considering flipping the arg order there too.

For example, if the middleware failure is a schema that encompasses a type that was already part of the app, I guess it makes sense to do the encoding with the middleware-supplied schema? But I can see a counter-argument to that too.

If we don't want to flip the arg order, an alternative solution in the same vain as this one, would be to have addError filter out any HttpApiDecodeError schemas from the union members while "unionifying" them, and then tag it back on at the end.