Loopback try to convert strings with numeric values into integer values

[rkmax]

I have a model that extends PersistedModel with some fields and relations nothing fancy. today on production server users report a error a 404 error openning a specific record I dont know if more records present the same problem. Is an default method findById

My model is named Profile by default the url to retrieve a profile is

http://localhost:8080/api/Profiles/:id

The curious thing here is only happens with one record, so if I call

http://localhost:8080/api/Profiles/566728794091712276797523

{
   "error" : {
      "name" : "Error",
      "status" : 404,
      "statusCode" : 404,
      "stack" : "Error: Unknown \"Profile\" id \"566728794091712276797523\".\n    at Function.convertNullToNotFoundError (/home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/loopback/lib/persisted-model.js:81:17)\n    at invokeRestAfter (/home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/loopback/node_modules/strong-remoting/lib/rest-adapter.js:451:25)\n    at /home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/async/lib/async.js:607:21\n    at /home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/async/lib/async.js:246:17\n    at iterate (/home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/async/lib/async.js:146:13)\n    at /home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/async/lib/async.js:157:25\n    at /home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/async/lib/async.js:248:21\n    at /home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/async/lib/async.js:612:34\n    at /home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:626:11\n    at execStack (/home/rkmax/DeMyProjectpment/BIX/MyProject/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:460:7)",
      "code" : "MODEL_NOT_FOUND",
      "message" : "Unknown \"Profile\" id \"566728794091712276797523\"."
   }
}

but if I call from a test.js file

var app = require('./server/server');

var Profile = app.models.Profile;

var profileCallback = function(err, profile) {
  console.log(profile);
}


Profile.findById('566728794091712276797523', profileCallback);

it works!!! returns me the object without problems O.o

this are my loopback-related packages

├── grunt-loopback-sdk-angular@1.1.2
├── loopback@2.22.2
├── loopback-boot@2.14.0
├── loopback-component-passport@1.5.0
├── loopback-connector-mongodb@1.13.0
├── loopback-connector-postgresql@1.7.1
├── loopback-datasource-juggler@2.41.1
├── loopback-explorer@1.8.0
├── loopback-sdk-angular@1.5.0
├── loopback-storage-service@1.0.4
├── loopback-testing@1.2.0

using the debug string loopback:connector:mongodb I found the following lines

With the record with problems

 cmd: 
   { find: 'quebloprod.Profile',
     limit: 0,
     skip: 0,
     query: { _id: 5.667287940917123e+23 },
     slaveOk: true,
     readPreference: { preference: 'primary', tags: undefined, options: undefined } },

With a record without problems

cmd: 
   { find: 'quebloprod.Profile',
     limit: 0,
     skip: 0,
     query: { _id: 566642f7a03be2e8751aa42c },
     slaveOk: true,
     readPreference: { preference: 'primary', tags: undefined, options: undefined } },

I think is the form how loopback try to convert the arguments received and if you see the id with problems does not have any letter on it so converts that to an integer and that is the problem.

even in another place of my application i found that when send strings with only numbers loopback try to converts to integer that I have to built a workaround for that

[rkmax]

There's some way to edit a remote method. I tried with the following without success

module.exports = function(app) {
  var Profile = app.models.Profile;

  Profile.sharedClass._methods.forEach(function(value, methodIndex) {
    if (value.stringName === 'findById') {
      Profile.sharedClass._methods[methodIndex].accepts.forEach(function(argument, argIndex) {
        if (argument.arg === 'id') {
          app.models.Profile.sharedClass._methods[methodIndex].accepts[argIndex].type = 'string';
        }
      });
    }
  });
};

[davidcheung]

Related PR : #1221

[stevegaossou]

I'm getting this exact issue as well. I'm using the Postgres connector and I am using BIGINT IDs.

My problem is that I am using BIGINT as the ID data type in the DB schema, but I need to use String, not Number, for the data type within Loopback (since JavaScript Number cannot fully represent a BIGINT).

So I have something like this in my model.json:

    "userId": {
      "type": "String",
      "id": true,
      "required": true,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "user_id",
        "dataType": "bigint",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "NO"
      }
    },

If I switch to Number, the problem goes away, but obviously I cannot do that because the BIGINT value gets truncated:

    "userId": {
      "type": "Number",
      "id": true,
      "required": true,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "user_id",
        "dataType": "bigint",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "NO"
      }
    },

Is there any chance this issue will be resolved in a release coming out soon?

[bajtos]

This should have been fixed by strongloop/strong-remoting#343 in the upcoming LoopBack 3.0 version (currently a Release Candidate).

[wilywork]

i have this problem..
when send to server a array: styles:["1","3","2"] the server convert to [1,2,3].
loopback version 3.26.0
solution for this?

[bajtos]

@wilywork Please create a small application we can use to reproduce the issue, see https://loopback.io/doc/en/contrib/Reporting-issues.html#loopback-3x-bugs. Ideally, there should be a failing test reproducing the HTTP call you are making. Once you have the app, then please open a new issue.

Resurrecting 2+ year old issues does not work well for us, the maintainers. Thank you for the understanding.