Skip to content

Disable default schema validation in UserStorageController #6074

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

Conversation

mirceanis
Copy link
Contributor

@mirceanis mirceanis commented Jul 8, 2025

Explanation

  • What is the current state of things and why does it need to change?
    Currently, public UserStorageController methods that interact with the storage SDK implicitly enforce schema validation (validateAgainstSchema: true) without providing an option to override this behavior. This default is not suitable for all scenarios, as some consumers may need to store data that does not conform to a predefined schema or manage schema validation externally.

  • What is the solution your changes offer and how does it work?
    This PR updates all relevant public UserStorageController methods to set validateAgainstSchema: false by default when calling the underlying storage SDK. This change provides greater flexibility, allowing consumers to store data without mandatory schema validation, aligning with use cases where schema enforcement is not required or handled elsewhere.

  • Are there any changes whose purpose might not obvious to those unfamiliar with the domain?
    The performDeleteStorageAllFeatureEntries and performBatchDeleteStorage methods previously did not include the validateAgainstSchema parameter. This PR adds it with the value false to ensure consistent behavior across all public storage operations.

References

Changelog

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
  • I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

- Set validateAgainstSchema to false in all UserStorageController public methods
- This allows the storage SDK methods to bypass schema validation by default
- Updated methods: performGetStorage, performGetStorageAllFeatureEntries, performSetStorage, performBatchSetStorage, performDeleteStorage, performDeleteStorageAllFeatureEntries, performBatchDeleteStorage
@Copilot Copilot AI review requested due to automatic review settings July 8, 2025 12:39
@mirceanis mirceanis requested a review from a team as a code owner July 8, 2025 12:39
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR disables mandatory schema validation (validateAgainstSchema) by default across all public methods in UserStorageController, allowing consumers to bypass schema enforcement when necessary.

  • Changed validateAgainstSchema from true to false in existing SDK calls.
  • Added validateAgainstSchema: false to delete-all and batch-delete methods.
  • Did not include corresponding test or documentation updates.
Comments suppressed due to low confidence (2)

packages/profile-sync-controller/src/controllers/user-storage/UserStorageController.ts:535

  • Update the method JSDoc/docs to reflect that validateAgainstSchema is now false by default for public storage methods.
  ): Promise<string | null> {

packages/profile-sync-controller/src/controllers/user-storage/UserStorageController.ts:538

  • Add or update unit tests to verify the new default behavior of validateAgainstSchema: false so that changes are validated and prevent regressions.
      validateAgainstSchema: false,

@mirceanis mirceanis marked this pull request as draft July 8, 2025 12:40
@mirceanis mirceanis closed this Jul 8, 2025
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.

2 participants