Store cart accepts fractional line-item quantity: 0.1 is stored as 0 and makes the cart uncompletable

[Uankur]

The store cart line-items endpoint validates quantity with z.number().gt(0) but not .int(), so a
fractional quantity passes validation and is coerced on store. 0.1 becomes quantity 0, which the
completion step then refuses, so the cart can never be paid for. 1.5 becomes 2, so a shopper who
asks for 1.5 is charged for two.

Medusa 2.20.1, stock starter, Postgres.

Steps:

1. POST /store/carts with a region_id (publishable key header set).
2. POST /store/carts/{id}/line-items with {"variant_id":"","quantity":0.1}
3. Returns 200. GET /store/carts/{id} shows the line item at quantity 0, item_total 0.
4. POST /store/carts/{id}/complete fails, and the item cannot be raised off 0.

I expected quantity to be validated as an integer, the same way the endpoint already rejects 0
and -1. A quantity the cart accepts should be one checkout can take.

Same endpoint, other values: 0.5 -> 1, 1.2 -> 1, 1.5 -> 2, 2.7 -> 3. The string "3" is rejected.
So the guard catches the wrong shapes but not fractions.

In 2.20.1 the store carts validators define line-item quantity as z.number().gt(0). Adding .int()
would close it.

This is the same class as #13363, which was closed as completed, but it still reproduces on 2.20.1.

[medusa-os-bot]

Thanks for reporting this! We've labeled it as a bug and will investigate.

The store cart line-item quantity validators in packages/medusa/src/api/store/carts/validators.ts use z.number().gt(0) (and z.number().gte(0) for the update endpoint) without the .int() constraint. Because the underlying database column is defined as INTEGER NOT NULL, fractional values (e.g. 0.1) pass API validation but get silently truncated by Postgres — 0.1 becomes 0, which then causes cart completion to fail. The fix is to add .int() in all three quantity validator definitions in that file (lines 10, 76, and 84). Straightforward one-line changes per validator; good candidate for a community contribution.