Skip to content

Conversation

@AdamFipke
Copy link
Collaborator

@AdamFipke AdamFipke commented Aug 11, 2025

Description

Makes forbidNonWhitelisted false. I wanted to put this into a PR to see if this breaks any tests.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update
  • This requires a run of yarn install
  • This change requires an addition/change to the production .env variables. These changes are below:
  • This change requires developers to add new .env variables. The file and variables needed are below:
  • This change requires a database query to update old data on production. This query is below:

How Has This Been Tested?

I manually tested this with one endpoint that had validateNested with extra properties. With it true it would throw an error to the user. With this false it will now just drop the extra properties.

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code where needed
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have checked that new and existing tests pass locally with my changes
  • Any work that this PR is dependent on has been merged into the main branch
  • Any UI changes have been checked to work on desktop, tablet, and mobile

@AdamFipke AdamFipke requested a review from bhunt02 August 12, 2025 01:05
Copy link
Collaborator

@bhunt02 bhunt02 left a comment

Choose a reason for hiding this comment

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

i mean it's probably fine, i thought you wanted to keep it true though for route validation?

@AdamFipke
Copy link
Collaborator Author

AdamFipke commented Aug 13, 2025

i mean it's probably fine, i thought you wanted to keep it true though for route validation?

There's pros n cons either way. But I mostly wanted to do it this way since it will make #346 a lot easier since whoever does it probably won't need to manually test like all of those endpoints to see if our frontend was sending bad data. This can be merged when that happens

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.

3 participants