Integer truncation occuring for large values

[jbn]

I'm not familiar enough with dgraph to understand the internals yet, but I believe some sort of integer truncation is occurring in ?latest.

Here is the narrowed, diagnostic query I eventually wrote,

{
    ego(func: eq(user_id,  6938055918824420986))  {
        uid
        user_id 
        blocks (first: 1) {
            uid
            user_id
        }
    }

    # It doesn't come up!
    egoWithFilter(func: eq(user_id, 6938055918824420986))  {
        uid
        user_id
           blocks @filter(eq(user_id, 7833966286149215000)) {
            uid
            user_id
        }
    }
    
    # Using my idgraph, I did the same query.
    # Using the id returned by that it works
    # Note: the UID of the block matches.
    # Integers are being truncated?
    egoWithFilterExternalId(func: eq(user_id, 6938055918824420986))  {
        uid
        user_id
    	blocks @filter(eq(user_id, 7833966286149214958)) {
            uid
            user_id
        }
    }
}

and the output,

{
  "data": {
    "ego": [
      {
        "uid": "0x7a51",
        "user_id": 6938055918824421000,
        "blocks": [
          {
            "uid": "0x7a35",
            "user_id": 7833966286149215000
          }
        ]
      }
    ],
    "egoWithFilter": [
      {
        "uid": "0x7a51",
        "user_id": 6938055918824421000
      }
    ],
    "egoWithFilterExternalId": [
      {
        "uid": "0x7a51",
        "user_id": 6938055918824421000,
        "blocks": [
          {
            "uid": "0x7a35",
            "user_id": 7833966286149215000
          }
        ]
      }
    ]
  },
  "extensions": {
    "server_latency": {
      "parsing_ns": 27736,
      "processing_ns": 2991649,
      "encoding_ns": 32572,
      "assign_timestamp_ns": 777840
    },
    "txn": {
      "start_ts": 755297
    }
  }
}

The code passed all my golang tests but when exploring in ratel I couldn't figure out why it wasn't finding the relationships. The critical error in ratel seems to be reporting 7833966286149215000 in the json response yet the uid actually matches 7833966286149214958 and,

7833966286149215|000 
7833966286149214|958

seems telling. Thanks for your help!

[campoy]

Unfortunately, there's not much we can do on our side as this is a JavaScript issue.

$ parseInt("7833966286149214958")

7833966286149215000

This is why twitter itself changed tweet IDs from integers to strings.

More info: https://stackoverflow.com/questions/15869275/json-not-converting-long-numbers-appropriately