Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: Decimal numbers *.0 are converted to integers #1768

Closed
AHOCHWE opened this issue Mar 12, 2024 · 2 comments
Closed

[BUG]: Decimal numbers *.0 are converted to integers #1768

AHOCHWE opened this issue Mar 12, 2024 · 2 comments

Comments

@AHOCHWE
Copy link

AHOCHWE commented Mar 12, 2024

Description

It seems that Bruno performs a conversion when a decimal number from the pattern *.0 is sent to the API. Bruno perform a conversion to an integer which leads to some issues in our API and their behavior because it expects a decimal number and not an integer.

image

@mjhcorporate
Copy link
Contributor

Unfortunately, this is a well-known problem with JSON (see, for example, this note in the FHIR spec). JSON only has on number type, and most serializers throw away trailing zeros and trailing decimal points.

In general, I highly recommend sending the numbers as strings if you care about the number format. Anything else is bound to break at some inconvenient time.

BUT... bruno should of course cover this use-case. Currently, for json-bodies, bruno builds a JS object and then serializes it. This changes several things:

  • trailing zeros (and possibly the decimal point) are omitted
  • the JSON formatting is stripped
  • the order of the properties can potentially change (in reality, the order stays constant)
  • duplicate properties are deduplicated (last property with same name "wins"

Naturally, this is what you want for proper json requests, but bruno should also be able to send slightly improper json requests! After all, it's a testing tool.

One possible workaround that should work (but doesn't, because of a separate bug) is: Set the body-type to text, and manually set the Content-Type to application/json. That way, you have full control over the request body.

image

Unfortunately, there is a separate bug that sometimes (not always) encodes the body as json (see below). I think there is an existing issue for this, but I have to look it up.


To see the body that bruno sends, use netcat as "echo-server": nc -l 8000. You can then send a request to localhost:8000, and it will be printed to the command line.

Together with the text-body + manual content-type-header trick, this leads to:

> nc -l 8000
POST / HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json
request-start-time: 1710330826355
User-Agent: axios/1.6.7
Content-Length: 17
Accept-Encoding: gzip, compress, deflate, br
Host: localhost:8000
Connection: close

{
  "num": 3.00
}

But sometimes, the result is something like this:

> nc -l 8000
POST / HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json
request-start-time: 1710331067917
User-Agent: axios/1.6.7
Content-Length: 44
Accept-Encoding: gzip, compress, deflate, br
Host: localhost:8000
Connection: close

"{\n  \"num\": 3.00,\n  \"num\": 4.00,\n}\n"

@helloanoop
Copy link
Contributor

This has been fixed as a part of PR #2773, and will go out in the v1.27.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants