Error Coercing Value to type Int

Report a Dgraph Bug

What version of Dgraph are you using?

20.07.0

Have you tried reproducing the issue with the latest release?

Yes

What is the hardware spec (RAM, OS)?

Google Cloud VM

Steps to reproduce the issue (command/config used to run Dgraph).

I’m interfacing through the standard Dart library for value types and serialization (built_value) to serialize and store objects with fields of type DateTime. This library expects DateTime objects to be represented as integers. My schema defines these fields as integers and mutations to store values are accepted, but it looks from Ratel like they’re being interpreted by the DB as strings in at least some places. Query some data like the following:

Expected behaviour and actual result.

I get the data :smiley:

I get an error :frowning:

{"id":"3ea20d96-3c1f-43dd-8f4d-4eb95bf51287","payload":{"message":"Error coercing value '1.5883164e+15' for field 'birthday' to type Int. (Locations: [{Line: 6, Column: 5}])"},"type":"error"}

1 Like

When I change the schema to represent those fields as String, the data converts in Ratel…note the fields that had quotations no longer do. Once this happens, I don’t receive an error server-side but rather client-side in deserialization because the data is sent back as a string, even though it looks like an integer in Ratel. Mutations still work fine.

It seems like the server is getting confused about the correct type for the data, causing it to fail on integer parsing?

Dropping schema also doesn’t help.

Those numbers are huge, in BigInt category.

That is happening because the numbers are overflowing, see: Max value of Integer in Dart.

Try using:
A library like: json-bigint or use

P.S. Why not use the inbuilt DateTime type of Dgraph?

@abhijit-kar

Hmmm, I thought these microseconds-since-epoch values fell well within range…? I’ve have no issue with these values in the other databases I’ve used.

image

Unless I’m very confused (which is possible), a Javascript BigInt library doesn’t do anything for me…and neither does switching schema to DateTime:

  1. I’m using Dart, not JS…while I could build in custom serialization along the BigInt lines, it shouldn’t be necessary for another 250 years or so (~8e15 microseconds) given the calculation above and my experience with other DBs (SQL, Firestore).

  2. The parsing error is on your side, not mine; Dart has no trouble with those numbers using standard types in the serialization library.

  3. I suspect your DateTime format wants ISO8601 strings, whereas the standard dart serialization library uses micros since epoch. My serialized values simply don’t seem to save when using that type in schema.

Please let me know if I’m getting this wrong.

Dgraph expects: RFC 3339 format dates.

I pointed out possible issues and JavaScript solutions, so that if they made sense, you can use Dart equivalent.

Like using: https://www.npmjs.com/package/json-bigint library since the default parser falls short in Big Int category.

You are right, I was wrong. I should have tested my assumptions.

I am not from the core team, so @Neeraj, a little assistance please.

1 Like

I’m not very sure about this. @MichelDiz can you please look into this?

It is not clear to me what or where the issue is. You mentioned Ratel, but your issue is on Dart lib? I’ll assume that your issue is just between Dgraph and Dart. The way that Ratel shows data isn’t important for us at all. It isn’t a way to debug something on the Dart side.

So, is your issue related to Dart being able to send big Integer to Dgraph, and when you request back that data the value is changed a bit or very different? Or Dgraph somehow gives you strings (on dart side) instead of the type defined on schema? That could be the client you are using, we don’t support dart, you are using a third-party client.

The DateTime type also won’t help here. We just support the mentioned ones on the above comments. Third-party ones you have to use normal Scalar types and deal on your side.

Where this error come from? Is it Dart or Dgraph? I mean, the dart client receives the request and throws the error? Or the Dart’s compiler is throwing it?

Let’s stop using Ratel as a debug tool for this. It is a way to visualize queries. You should use Dart’s debug tools ou curl to see what data is coming from Dgraph. I suspect that this might be something related to the size of the integer. There is an issue tracking this. Also, there is a “Big-Int” PR waiting to be reviewed for some time.

It is from @harshil_goel, hey Harshil can you help us to identify what is the cause of this issue? Thanks!

Unless it comes from a Dgraph’s error handling, it is coming from the client. And as I said before, maybe is the int size. Your client receives the int, but it is smaller than the needed. It can’t be the type of the key. In general Dgraph sends the exact type back to the user in JSON format.

BTW, are you serializing it right? Dart doesn’t infer JSON out of the box. You have to create a structure for it.

1 Like

The error comes from graphql layer. In graphql we can’t accept variables > int32. I think @abhimanyusinghgaur is working on a fix for that right now.

8 Likes

OK cool, thanks all for the range of info. I’ll stop lending credence to Ratel; I just found it curious and possibly related that quotation marks were on type int.

@MichelDiz just to answer your questions (sorry, I wasn’t very precise in a few places): I’m using my own custom Dart Dgraph client, which depends on the most popular Dart GQL and value type + serialization libraries. I was confident in serialization because that library is long-verified Google production code, very widely used in Dart+Flutter. That payload message is coming from Dgraph, and the object holding it is constructed in the Dart GQL lib.

@abhijit-kar @harshil_goel
Sounds like the answers. I’ll add a serialization plugin that coverts my values to either RFC 3339 or BigInt-style formats for now, and will adjust when I see that fix go live. Thanks both!

Hey @CosmicPangolin1
I just merged the PR which supports Int64 as a scalar type in GraphQL. Note that:

Int64 can currently represent values in range [-(2^53)+1, (2^53)-1] without any error.
Values out of this range but representable by a signed 64-bit integer, may get coercion error.

It is now available in master and would be part of release v20.11

2 Likes

@abhimanyusinghgaur

Thanks for letting me know! I’ll migrate over as soon as I see a rc…or earlier :slight_smile:

Yep, just ran into this error and was trying to figure out the source myself. I was trying to store a phone number as a Int by stripping of the country code and removing any non numeric characters. What I soon realized is that my phone number is greater than 32 bit, lol. I’ll just have to use a string field until 20.11 :crossed_fingers:

I also struggled with this for quite some time as the latest docs identify int as supporting 64bit but that is not the case with Slash GraphQL service my backend is reporting v20.07.1-rc1

Any word on when this is coming to Slash?

Pinging @gja

Thanks @MichelDiz for tagging me. I’ll take a look and see how feasible it is.

Hi Andrew,

I spoke with the team, and they feel that this is something that will need a major upgrade to work. We’ll be likely going live with this fix at the end of this month

Tejas