openapi: enable strict schema validation by default and fix #4355
Conversation
Sonatype Lift is retiringSonatype Lift will be retiring on Sep 12, 2023, with its analysis stopping on Aug 12, 2023. We understand that this news may come as a disappointment, and Sonatype is committed to helping you transition off it seamlessly. If you’d like to retain your data, please export your issues from the web console. |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
| @@ -29,6 +29,7 @@ export const publicSignupTokenSchema = { | |||
| description: | |||
| 'The public signup link for the token. Users who follow this link will be taken to a signup page where they can create an Unleash user.', | |||
| type: 'string', | |||
| nullable: true, | |||
There was a problem hiding this comment.
I don't know what it means for this to be null, but it definitely can be in our tests. Does that mean we need to change our tests or is it actually nullable?
| @@ -6,7 +6,7 @@ export const tokenUserSchema = { | |||
| type: 'object', | |||
| additionalProperties: false, | |||
| description: 'A user identified by a token', | |||
| required: ['id', 'name', 'email', 'token', 'createdBy', 'role'], | |||
| required: ['id', 'email', 'token', 'createdBy', 'role'], | |||
There was a problem hiding this comment.
The name property is missing in responses in pretty much all of our tests, so I'm guessing it's not there. Should it be?
In fact, I don't know if it is ever used 🤔
There was a problem hiding this comment.
No, we definitely do use it sometimes: it's explicitly assigned to in UserService. I'm guessing that we do return it from the reset-password-controller as well if the user has a name.
| @@ -25,6 +25,7 @@ export const userSchema = { | |||
| description: 'Name of the user', | |||
| type: 'string', | |||
| example: 'User', | |||
| nullable: true, | |||
There was a problem hiding this comment.
name is null if the user has no name.
| this.openApiService.respondWithValidation( | ||
| 200, | ||
| res, | ||
| validateTagTypeSchema.$id, | ||
| { | ||
| valid: true, | ||
| tagType: req.body, | ||
| }, | ||
| ); |
There was a problem hiding this comment.
The only thing that's changed here (aside from formatting) is that we use the correct validateTagTypeSchema.$id instead of tagTypeSchema.$id in the response. This was probably a typo or copy/paste error.
| ...{ | ||
| ...customOptions, | ||
| experimental: { | ||
| ...(customOptions?.experimental ?? {}), | ||
| flags: { | ||
| strictSchemaValidation: true, | ||
| ...(customOptions?.experimental?.flags ?? {}), | ||
| }, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Enable strict schema validation unless it's been explicitly disabled. This applies to all app setup methods.
Enable strict schema validation by default. It can still be overridden by explicitly setting it to false.
I've also fixed the validation errors that appeared when turning it on. I've opted for the simplest route and changed the schemas to comply with the tests.