starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 16:55:59 +03:00

[GH-ISSUE #5970] [bug]: Hoppscotch truncates precision for long numeric values in the request payload #2345

New issue

Open

opened 2026-03-17 00:01:45 +03:00 by kerem · 1 comment

kerem commented

2026-03-17 00:01:45 +03:00

Owner

Originally created by @qiqingli on GitHub (Mar 10, 2026).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5970

Originally assigned to: @VivekNeer on GitHub.

Is there an existing issue for this?

I have searched existing issues and this bug hasn't been reported yet

Platform

Desktop App

Browser

Chrome

Operating System

macOS

Bug Description

Hoppscotch truncates precision for long numeric values in the request payload, resulting in incorrect parameter values.

Deployment Type

Self-hosted (on-prem deployment)

Version

26.2.1

Originally created by @qiqingli on GitHub (Mar 10, 2026). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5970 Originally assigned to: @VivekNeer on GitHub. ### Is there an existing issue for this? - [x] I have searched existing issues and this bug hasn't been reported yet ### Platform Desktop App ### Browser Chrome ### Operating System macOS ### Bug Description Hoppscotch truncates precision for long numeric values in the request payload, resulting in incorrect parameter values. ![Image](https://github.com/user-attachments/assets/27890b2e-c10b-47d4-839b-72275159260c) ![Image](https://github.com/user-attachments/assets/4ed40fb5-4913-42c9-bede-e3620e15206f) ### Deployment Type Self-hosted (on-prem deployment) ### Version 26.2.1

kerem added the

bug

need testing

labels

2026-03-17 00:01:46 +03:00

kerem commented

2026-03-17 00:01:57 +03:00

Author

Owner

@VivekNeer commented on GitHub (Mar 10, 2026):

Hello ><

I was able to reproduce this on the latest main (v2026.2.1) on Firefox.

This issue is due to js floating point precision issue where js uses 64 bit IEEE-754 doubles for all numbers so it can represent numbers exactly upto Number.MAX_SAFE_INTEGER = 2^53 - 1 = 9007199254740991.

The truncation isn't happening in the HTTP layer it happens earlier, during internal JSON preprocessing in the frontend before the request even leaves the browser. You can see this in the Network tab: the value the server receives is already wrong.

Example:

{
  "normalId": 123,
  "bigId": 9007199254740993,
  "bigId2": 99999999999999999
}

bigId: 9007199254740993 → truncated to 9007199254740992
bigId2: 99999999999999999 → truncated to 100000000000000000

Root cause:

The issue is in packages/hoppscotch-common/src/helpers/editor/linting/jsonc.ts. Before every JSON body is sent, it passes through stripComments() to strip JSONC comments and trailing commas. Internally this uses jsonc-parser's parseTree(), which converts numeric tokens into JavaScript number primitives. Any integer beyond Number.MAX_SAFE_INTEGER gets silently rounded at this point. Then JSON.stringify(node.value) serializes the already-truncated value.

Btw, lossless-json is already loaded as a dependency in the project but isn't being used in this serialization path.

Proposed fix:

jsonc-parser stores offset and length on every AST node pointing back to the original source text. For the "number" case in convertNodeToJSON, we can slice the original string instead of going through node.value:

// before
case "number":
  return JSON.stringify(node.value)

// after
case "number":
  return originalText.slice(node.offset, node.offset + node.length)

Note: The JS: badge in Firefox DevTools shows what JavaScript would parse the value as this is just a DevTools warning, not the actual sent value. The value on the left is what's transmitted, which is now correct.

This is a minimal, safe change only the number case changes, and it reads the exact characters the user typed rather than round-tripping through a lossy JS number.

I'd like to work on this fix. Could this be assigned to me?

@VivekNeer commented on GitHub (Mar 10, 2026): Hello >< I was able to reproduce this on the latest main (v2026.2.1) on Firefox. This issue is due to js floating point precision issue where js uses 64 bit IEEE-754 doubles for all numbers so it can represent numbers exactly upto `Number.MAX_SAFE_INTEGER` = 2^53 - 1 = `9007199254740991`. The truncation isn't happening in the HTTP layer it happens earlier, during internal JSON preprocessing in the frontend before the request even leaves the browser. You can see this in the Network tab: the value the server receives is already wrong. **Example:** ```javascript { "normalId": 123, "bigId": 9007199254740993, "bigId2": 99999999999999999 } ``` <img width="822" height="611" alt="Image" src="https://github.com/user-attachments/assets/244dab4e-d5de-42cf-ab13-fa9d5f9b9d67" /> <img width="753" height="449" alt="Image" src="https://github.com/user-attachments/assets/baf2eaf4-711c-4da8-844a-18420ffa97d3" /> - `bigId`: 9007199254740993 → truncated to `9007199254740992` - `bigId2`: 99999999999999999 → truncated to `100000000000000000` **Root cause:** The issue is in `packages/hoppscotch-common/src/helpers/editor/linting/jsonc.ts`. Before every JSON body is sent, it passes through `stripComments()` to strip JSONC comments and trailing commas. Internally this uses `jsonc-parser`'s `parseTree()`, which converts numeric tokens into JavaScript `number` primitives. Any integer beyond `Number.MAX_SAFE_INTEGER` gets silently rounded at this point. Then `JSON.stringify(node.value)` serializes the already-truncated value. > Btw, `lossless-json` is already loaded as a dependency in the project but isn't being used in this serialization path. **Proposed fix:** `jsonc-parser` stores `offset` and `length` on every AST node pointing back to the original source text. For the `"number"` case in `convertNodeToJSON`, we can slice the original string instead of going through `node.value`: ```javascript // before case "number": return JSON.stringify(node.value) // after case "number": return originalText.slice(node.offset, node.offset + node.length) ``` <img width="747" height="650" alt="Image" src="https://github.com/user-attachments/assets/37606916-e461-42f4-a65a-f35d53cd4d66" /> > Note: The JS: badge in Firefox DevTools shows what JavaScript would parse the value as this is just a DevTools warning, not the actual sent value. The value on the left is what's transmitted, which is now correct. This is a minimal, safe change only the number case changes, and it reads the exact characters the user typed rather than round-tripping through a lossy JS number. I'd like to work on this fix. Could this be assigned to me?