Strings which are only numbers causes issues.

[nareshjois]

say a request is just
{ "data" : { "customerId" : "2343546576878989879789" } }

The Coerce function is over enthusiastic and parses the customerId to 234354657687898987 to 234354657687898980, this leads to incorrect values being passed around, Either the Regex test for isFloat needs to be corrected to handle numbers which javascript is good with or strings need not be parsed to floats as a whole.

[bajtos]

say a request is just
{ "data" : { "customerId" : "2343546576878989879789" } }

The Coerce function is over enthusiastic and parses the customerId to 234354657687898987 to 234354657687898980, this leads to incorrect values being passed around, Either the Regex test for isFloat needs to be corrected to handle numbers which javascript is good with or strings need not be parsed to floats as a whole.

Hello @nareshjois, I am writing an extensive test suite in #304 to capture the current behaviour of our coercion algorithm in different edge cases. I have difficulties reproducing your problem, could you please help me by providing more information?

AFAICT, in the current strong-remoting version:

when you specify:

    setRemoting(PersistedModel.prototype, 'updateAttributes', {
      description: 'Update attributes for a model instance and persist it into the data source.',
      accessType: 'WRITE',
      accepts: { arg: 'data', type: 'object', http: { source: 'body' }, description: 'An object of model property name/value pairs' },
      returns: { arg: 'data', type: typeName, root: true },
      http: { verb: 'put', path: '/' },
    });

and POST a request with JSON body

{ "data" : { "customerId" : "2343546576878989879789" } }

then no coercion is applied and the input ("accepts") argument is set to

{ "data" : { "customerId" : "2343546576878989879789" } }

The same applies when the input argument specified http.source: "form", in which case data becomes

{ "customerId" : "2343546576878989879789" }

What am I missing?

Is it possible that this issue has been already fixed in v2.16.1 by 34b0665?

/cc @STRML

[bajtos]

Closing as fixed.