Stefan VanBuren

I'd be willing to put together a PR with the merge conflicts fixed here, as well as the benchmark fix. If we did this, how would we want to approach...

I've been playing around with this for a bit and have it mostly working - the only issue is that given the current implementation, if we make the threshold configurable...

this is part of the GraphQL spec: https://facebook.github.io/graphql/June2018/#sec-Data >If an error was encountered during the execution that prevented a valid response, the data entry in the response should be null.

@VincentVW https://graphql.github.io/graphql-spec/June2018/#example-90475 - I'd agree that you shouldn't be forced to give `null` back in that situation.

I don't think it's supported quite yet - there's an [open PR](https://github.com/bufbuild/buf/pull/1345) for it though. I'd assume it'll make it out in the next release.

I also saw this ... maybe a week ago? And I think it's maybe happened once before?

_maybe_ the GitHub UI merging, followed by a rebase-pull? (I'm really unsure 😄). Maybe if you had a local commit you hadn't pushed on `develop`, followed by a GitHub merge...

yeah, good point. no idea then :/

packer!

@ghonchesefidi I haven't used it myself, but have you tried something similar to what's outlined here: https://blog.sneawo.com/blog/2017/04/14/migrations-for-mongoengine/ ?