Too many decimals in API responses about backend-replacement HOT 3 CLOSED

This no longer seems to be the case.

However, I scientific notation is used a lot. Not sure if we are loosing precision here, but anyhow, I would prefer int values like "100000000" instead of "1e+8".

from backend-replacement.

I have a branch where I feed in forkdelta orders from the FD websocket API like it is done in production for ED orders from the ED API.

This shows that we emit orders that are not accepted by our own standards.

E.g.:

forkdelta_observer_1 | forkdelta_observer WARNING FD Order rejected: Invalid message format: {'data': {'id': '0x2848870854bc273a90b43b3114395c0bae03c1433ac9a9235267b12b3f40c817_sell', 'user': '0xf32d616182f0ed57d845d0f9cf8db2d3829c79ec', 'state': 'OPEN', 'tokenGet': '0x0000000000000000000000000000000000000000', 'amountGet': '9.5000e+16', 'tokenGive': '0x327682779bab2bf4d1337e8974ab9de8275a7ca8', 'amountGive': '1e+20', 'expires': '5157689', 'nonce': '1.12363e+9', 'v': 27, 'r': '0x154b2f33f8d5b58647c070be9f0c6f5465cf85740dab010640d7b29f1c956451', 's': '0x1f58901627acc9a5cc66fd3e889576e0a44fb33722c0f8b67add25d1172b5009', 'date': '2018-02-14T19:56:27.416884', 'updated': '2018-02-22T17:25:34', 'availableVolume': '3.066443421e+11', 'ethAvailableVolume': '3.066443421e-7', 'availableVolumeBase': '291312125', 'ethAvailableVolumeBase': '2.913121250e-10', 'amount': '3.066443421e+11', 'amountFilled': '0', 'price': '0.00095'}, 'errors': {'nonce': ["field 'nonce' cannot be coerced: invalid literal for int() with base 10: '1.12363e+9'", 'must be of integer type']}}

Same happens with expires field.

=> We should generally not emit ints in scientific notation.

forkdelta_observer_1 | forkdelta_observer WARNING FD Order rejected: Invalid message format: {'data': {'id': '0xa223fa30c8a272cc14d4bc1165f345762ef7addc04eed5511ab2b09737863f4d_buy', 'user': '0xe964115135319875c5a431a6e24df2c5986d6bfb', 'state': 'OPEN', 'tokenGet': '0x1bb9e8ea817d56eccc212ce63f7da95298f98719', 'amountGet': '1.0e+9', 'tokenGive': '0x0000000000000000000000000000000000000000', 'amountGive': '0', 'expires': '5142301', 'nonce': '3388406454', 'v': 28, 'r': '0xcf6954b39d9c7fd0e5a233b365a86b6426cb9d9fb1fac8268c4ca25ec8611cce', 's': '0x6ba1b60cfe8f3361a52a9e1a55af229c33bbe73173ac4c6f52cea8d654c8ab89', 'date': '2018-02-21T21:00:29.956238', 'updated': '2018-02-21T21:00:29.956238', 'availableVolume': '1.0e+9', 'ethAvailableVolume': '10000000.00', 'availableVolumeBase': '0', 'ethAvailableVolumeBase': '0', 'amount': '-1.0e+9', 'amountFilled': '0', 'price': '0e+2'}, 'errors': {'amountGive': ['min value is 1']}}

We no longer accept "amountGet/Give == 0", but there are still orders like this in the prod DB. Should we clean this up?

from backend-replacement.

This has been fixed.

from backend-replacement.