Loopback: ID's being converted to scientific notation

[GlennMurphy]

As mongo's generated ID's get larger loopback seems to convert mongo's auto generated ID's to scientific notation integers instead of keeping them as strings.

For instance. I have a document with the auto generated ID "562547717371313000366169"

If I request document via the endpoint:

/documents/562547717371313000366169

Loopback returns that it can not find the model. I hooked this call with the 'access' hook and logged the where query.

query:
{
where: { id: 5.62547717371313e+23 },
limit: 1,
offset: 0,
skip: 0,
}

I can get around this by querying documents with the following URL:

/documents?filter={"where":{"id":"562547717371313000366169"}}

But now I can't use any of the generated endpoints for the item.

[superkhau]

Can you provide a link to a test project on GitHub? See https://github.com/strongloop/loopback/wiki/Reporting-issues#bug-report

[Amir-61]

Hey @GlennMurphy

You are right if you are using loopbacl-connector-mongodb the IDs get coneverted to scientific notation integers; but in terms of the problem you encountered, could you please provide a sample repo using loopback-sandbox, so then we can see what is the problem in your example repo...

Thanks so much!

[Amir-61]

@GlennMurphy Any update on this?

[ryankennedyio]

@Amir-61 We've just run into this issue too. I have about 30 objects in my load testing account that now cannot be accessed nor deleted.

A sample repo shouldn't be needed for this issue -- fairly obvious as to the cause and solution, no ?

[superkhau]

@ryankennedyio Would you like to submit a PR with the fix?

[GlennMurphy]

Sorry, I've been extremely busy and haven't gotten around to replying here. I have solved this in my own project. Will submit a fix here shortly.

[ryankennedyio]

Awesome @GlennMurphy

I had a team member look into it, but it seems like there's a few core Loopback packages where the change might need to be submitted. @diesal11 any findings?

[diesal11]

@Amir-61 @superkhau I did some digging in attempt to find a simple-ish solution that I could PR. But the bug pops up in a few places. So here's what i found:

I've created an example repo so you can follow along, instructions are in the readme.

To cut a long story short, all PersistedModel endpoints that accept an id argument have their type set to 'any'. This means that whenever the given ID is a numeric string it gets converted/coerced into a JS number and our Scientific Notation bug comes up. So this is a loopback package issue in my opinion.

A simple fix I found for this is to change theID arg types to String in PersistedModel.js, Although i'm not sure what implications that might have on other connectors that only have numeric IDs?

However, this still leaves a bug where the id is coerced into a number when it is part of a filter on find/fineOne and any relevant endpoints. Im not 100% sure how to tackle this one, nor have i had the time unfortunately. I believe the issue would need to be solved in strong-remoting though, as any number types large enough will have the same bug. Which is more of a overall Javascript quirk.

Also worth noting that this bug will only happen once a DB/Connector generates an ID that is over 20 chars and only numbers.

[ryankennedyio]

@Amir-61 @superkhau Any news?

@GlennMurphy what was your solution?

[superkhau]

@ryankennedyio Sorry for the late response, unfortunately I have not had time to look into it. @0candy Can you try to reproduce this and escalate it to a bug after confirmation with the sample repo provided by @diesal11? This will probably be a major issue once you confirm it.

[0candy]

Confirmed the bug with the sample repro provided.

[bajtos]

This should be fixed by https://github.com/strongloop/strong-remoting/pull/343 in LoopBack 3.0 (alpha).

@0candy @superkhau could you please verify?

[superkhau]

@0candy Confirm please? I remember talking to you about this.

[0candy]

Verified that it works with LB 3.0 (alpha). Closing issue.