Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
isClientSafe DDP errors #8756
This is a possible implementation of something we discussed about a year ago here: https://forums.meteor.com/t/meteor-guide-methods/19662/34?u=aldeed
If any thrown error has
The goal here is for NPM packages like simpl-schema to be able to throw validation or other errors and have them sent back to the client call.
One question: Should it do the same thing for any sanitizedError that has
I think a similar thing would be useful for GraphQL as well, do we think it might be nice to promote isClientSafe?
Might it be better instead of a flag to maybe have a version of the error that is client safe, as a field on the error object? Like it would have validation information but maybe not stack traces?
@stubailo, I think that might be a good idea, it gives the package maintainers more control of the shape of the exception that would be forwarded to the client. But, doesn't the forwarded error need to be an instance of
On the wire, it's just a JSON blob - so the client can make that into a
We can promote this mechanism in the Apollo
@stubailo I'm happy to adjust to whatever implementation people want. Just wanted to get something up. My only priority is removing the need for any dependencies, and still being able to pass back additional error details JSON, which SimpleSchema currently does using the
"To specify an error that is safe to be sent back to the remote caller, set
It could then attempt to generically serialize the error (standard error props + "own" props) rather than explicitly looking for "reason", "details", etc.
Let me know what you all are thinking, and I can update the PR. I just don't know how deep into the DDP spec I should make changes. It should definitely be possible to remove all
As an aside, mdg:validation-error could also be ported to an npm package following this new spec.
After some discussion this morning in our triage meeting, I'm a fan of the
isClientSafe property as a convention that can be respected by multiple interacting libraries/frameworks, given the limitations of
instanceof when you don't have access to the constructor function.
To move forward with this PR:
Meteor.Errorconstructor should set
this.isClientSafe = true, so that all
Meteor.Errorobjects pass either test. This should also give us
- We should replace all
error instanceof Meteor.Errorchecks with
error && error.isClientSafe.
- The current implementation needs to change a bit to prevent accidentally wrapping
Meteor.Errorobjects with new
With those issues addressed, I like this idea a lot!
referenced this pull request
Jun 9, 2017
@benjamn I made the requested changes. You said to replace
We will be bumping at least the minor version of both packages in Meteor 1.5.1, so they should both be forced to update by the Meteor release. Note: we're only bumping the patch version of