Fix crash in RawRepresentable parsing by throwing couldNotConvert

[MrAlek]

This prevents a crash if receiving an unexpected enum case. Instead, the code will throw an error.

I suggest this should be merged in as a hot fix, creating a 0.5.7 release.

I'm also about to make optional enums parse as nil instead of throwing an error to make the client more robust to schema changes. Would you consider it a good default behavior? Ideally, you would both get nil for that enum case and an error in the GraphQLResult struct but I don't know if that's tricky in the current framework code.

[apollo-cla]

@MrAlek: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[MrAlek]

@martijnwalraven Could you have a look at this? :)

[martijnwalraven]

Yep, sorry I didn't get to this sooner. It looks like a reasonable fix, but master is in a weird state right now. If I merge this, I'm not sure how to do a 0.5.7 release based just on 0.5.6 + this fix. Any suggestions?

I hope we can do a proper new release next week, after I've merged some remaining WIP.

[MrAlek]

I would branch off 0.5.6, merge this in manually & release a 0.5.7 tag from that branch, then merge into master.

[martijnwalraven]

Yeah, I was afraid it would involve some manual Git sorcery :) I can see how I can branch off 0.5.6 and merge this in to do a 0.5.7 release, but I don't think I can just merge that into master without creating conflicts and messing up the history.

I'd rather not spend time on this now, because the sooner I can finish the remaining work, the sooner we can do a proper new release, including this fix.

[MrAlek]

I'd consider this a pretty important fix since without it, any app using the framework crashes if a server would update its schema with a new enum value. For us though, it's no problem, we're running our own fork meanwhile.

Something to consider might be to use a git flow branching strategy for this repo. Then you could have a develop branch where active development on bigger releases is at, while fixes & small improvements can still be merged into master.

[martijnwalraven]

Yeah, I should have handled this better. In most cases, I think development should happen on separate PRs. But because I was making some major changes and didn't want people to work on PRs based on an outdated master, I figured merging the WIP would make things easier. I hadn't expected it to take this long though...