Revert stricter scalar parseValue coercion #3186
Conversation
| 1234567l | 1234567 | ||
| new AtomicInteger(42) | 42 | ||
| Integer.MAX_VALUE | Integer.MAX_VALUE | ||
| Integer.MIN_VALUE | Integer.MIN_VALUE |
There was a problem hiding this comment.
Some reorganising so these two adjacent tests are ordered in the same way
| new BigInteger("42") | 42 | ||
| new BigDecimal("42") | 42 | ||
| 42.0f | 42 | ||
| 42.0d | 42 |
| value | result | ||
| 123 | "123" | ||
| true | "true" | ||
| customObject | "foo" |
There was a problem hiding this comment.
As all Java objects must have a toString method, there will always be a result for parseValue with the looser coercion.
|
👋 howdy! I've recently been looking into upgrading a v18.1 service to v20.2 and have been looking into how to safely migrate to this (now reverted) part of the update. For example, an early attempt at this was to try modifying scalars like Boolean to use a new Coercing that could log compatibility issues. I couldn't get this to work, as the standard Boolean and its Coercing are baked into skip/include directives in a way that makes them difficult to replace. It would be great to get this un-reverted eventually, but for now I'm interested in following any thinking about what a migration solution might look like. Is there a way to keep tabs on this? |
|
hey @jbellenger ... so we decided to reverted it, because even if we think this is the right behaviour there is a chance of some existing clients could break. Have a look at #3188 and maybe comment if that would help you: we plan to introduce a temporary internal only API for one or two releases that will allow everybody to migrate more safely. |
|
You can keep track of the progress on #3191, I'll continue to add changes related to |
…ion-revert Add backport of scalar coercion reversion PR #3186
Reverts stricter
parseValuecoercion for built-in scalars String #3030 and Boolean, Float, and Int #3042.We've received feedback that this
parseValuebreaking change is causing an issue with clients expecting the old behaviour. Whilst this change was to alignparseValuecoercion with the JS reference implementation, we want to temporarily revert this change while we work on a better migration solution.The stricter parseValue coercion was previously released with GraphQL Java 20.0.
JS implementation: https://github.com/graphql/graphql-js/blob/main/src/type/scalars.ts