-
-
Notifications
You must be signed in to change notification settings - Fork 594
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
fix: Remove validation error handler option error
from various methods of Parse.Object
#2445
Conversation
Thanks for opening this pull request! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## alpha #2445 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 64 64
Lines 6256 6256
Branches 1452 1446 -6
=========================================
Hits 6256 6256 ☔ View full report in Codecov by Sentry. |
Now is a good time to merge any breaking changes. We can release with Parse Server 8. |
Parse.Object.set
option for validation errorParse.Object.set
option error
for validation error handling
BREAKING CHANGE: Removes the validation error option from @dplewis Is this proposed changelog entry correct? |
Parse.Object.set
option error
for validation error handlingParse.Object.set
and Parse.Object.setACL
option error
for validation error handling
There is also Edit: Basically setting / updating a field with invalid key or acl will throw error now. Before you would have to save first to get the error. If a developer fixed all errors before updating to using this change there shouldn't be any issues. If they just set fields and never saved then that would be a breaking change |
I guess these are 2 changes then:
Could we do only (1) and not (2), if it's not necessary for (1)? In any case, if the primary purpose of this PR is (1), then this would be a breaking change either way, because it's possible that someone is using it, right? |
If you didn't pass an error option the error would be slienced but now it's thrown
The error would get thrown before you get a chance to save. |
So the original behavior is:
New behavior with this PR:
Is that correct? |
This is correct. Users have reported that save didn’t throw at all like #1386 and there were a few other examples but I can't find them. |
Do you think it makes more sense to throw on .set or on .save? Throwing on .save seems to make more sense to me, because .set seems more like a non-op. Do we have any other similar examples in the SDK? |
I think it should throw on .set because it's easier to debug where the error is in the stack trace. Also this PR adds a message for |
BREAKING CHANGE: Removes the error handler option @dplewis Is this proposed changelog entry correct? |
LGTM! |
Parse.Object.set
and Parse.Object.setACL
option error
for validation error handlingerror
from various methods of Parse.Object
error
from various methods of Parse.Object
error
from various methods of Parse.Object
# [6.0.0-alpha.1](5.3.0-alpha.6...6.0.0-alpha.1) (2025-02-16) ### Bug Fixes * Remove validation error handler option `error` from various methods of `Parse.Object` ([#2445](#2445)) ([52ddaee](52ddaee)) ### BREAKING CHANGES * Removes the error handler option `error` from `Parse.Object.set`, `Parse.Object.setACL`, `Parse.Object.unset`, `Parse.Role.setName` and instead throws on validation error. Previously, if the `error` option was set, the handler was invoked if a validation error occurred on `Parse.Object.set`, and if no handler was set, an error was thrown on `Parse.Object.save`. The new behavior is that an error is thrown at `Parse.Object.set`. For example, instead of using `Parse.Object.set(key, value, { error: ... })` wrap `Parse.Object.set(key, value)` into a `try/catch` block. ([52ddaee](52ddaee))
🎉 This change has been released in version 6.0.0-alpha.1 |
# [6.0.0](5.3.0...6.0.0) (2025-03-02) ### Bug Fixes * `Parse.Hooks` requests have double forward slash in URL ([#2441](#2441)) ([1fc520c](1fc520c)) * `Parse.Query.findAll` not returning all objects with option `json: true` ([#2449](#2449)) ([f160b8c](f160b8c)) * Cannot pass `useMasterKey: false` to `Parse.Cloud.run` ([#2431](#2431)) ([abadac9](abadac9)) * Remove validation error handler option `error` from various methods of `Parse.Object` ([#2445](#2445)) ([52ddaee](52ddaee)) * Security upgrade dset from 3.1.3 to 3.1.4 ([#2277](#2277)) ([058f8e4](058f8e4)) ### Features * Add transaction to save and destroy on `Parse.Object` ([#2265](#2265)) ([2b55bdf](2b55bdf)) ### BREAKING CHANGES * Internal REST requests for `Parse.Hooks` use a URL that contains a double forward slash, for example `http://localhost/parse//hooks/functions`. This release changes the double forward slash to a single forward slash. ([1fc520c](1fc520c)) * Removes the error handler option `error` from `Parse.Object.set`, `Parse.Object.setACL`, `Parse.Object.unset`, `Parse.Role.setName` and instead throws on validation error. Previously, if the `error` option was set, the handler was invoked if a validation error occurred on `Parse.Object.set`, and if no handler was set, an error was thrown on `Parse.Object.save`. The new behavior is that an error is thrown at `Parse.Object.set`. For example, instead of using `Parse.Object.set(key, value, { error: ... })` wrap `Parse.Object.set(key, value)` into a `try/catch` block. ([52ddaee](52ddaee))
🎉 This change has been released in version 6.0.0 |
Pull Request
Issue
You can pass an option in
set
to handle validation errors. The problem is this option isn't well documented and isn't widely used. This method of error handling is called backbone and was removed in 2.0.0. There are two errors (invalid key name and invalid acl) that are being checked. This could potentially be a breaking change if a user is setting invalid fields and never saving as saving would throw the errors.Closes: #2104
Approach
options.error
Parse.Error.INVALID_KEY_NAME
set
now throws validation errorsTasks