[brightpixel-dev]

Closes #2

What changed

• prisma/schema.prisma — All Float fields on monetary and weight columns replaced with Decimal @db.Decimal(36, 7):

  • VestingSchedule.amount
  • Proposal.amount
  • Vote.weight
  • Stream.totalAmount, Stream.claimedAmount
  • ClaimEvent.amount
  • TreasuryEvent.amount (nullable)

• prisma/migrations/20260620000000_replace_float_with_decimal/migration.sql — Safe in-place migration:

  • Preflight DO block validates no existing values exceed NUMERIC(36,7) range before altering
  • ALTER TABLE ... ALTER COLUMN ... TYPE NUMERIC(36,7) USING column::NUMERIC(36,7) for each affected column
  • Rollback statements included as comments

• src/routes/vesting.ts — Vesting progress endpoint updated:

  • schedule.amount * progress replaced with schedule.amount.mul(new Decimal(progress)) (Decimal arithmetic)
  • totalAmount and vestedAmount serialised as strings in JSON response to prevent precision loss at the API boundary
  • progress (a display ratio 0–1) remains a JS number — floating-point is acceptable for percentages

Why

DOUBLE PRECISION has ~15–17 significant decimal digits. Stellar on-chain amounts use 7 decimal places (1 XLM = 10 000 000 stroops); large stroop values (e.g. 1 000 000 000 × 10^7 = 10^16 stroops) cannot be represented exactly in binary float. NUMERIC(36,7) stores up to 10^29 XLM exactly and eliminates rounding at every layer — database, application arithmetic, and JSON serialisation.

How to test

1. prisma migrate deploy — preflight passes, columns alter cleanly
2. Insert a vesting schedule with amount = 10000000000.0000001 (large value with 7 decimal places)
3. GET /api/vesting/:id/progress — totalAmount and vestedAmount are returned as exact decimal strings, not floats
4. Insert a Vote with weight = 0.1234567 — value stored and retrieved without rounding
5. flutter analyze / npx tsc --noEmit on affected files — no new errors

[diiabblo]

Review: Float to Decimal migration

The migration SQL and schema changes are clean -- the preflight validation, NUMERIC(36,7) precision, and rollback comments are all correct. A couple of gaps need addressing:

Requesting changes

Other routes that read monetary fields are not updated (src/routes/history.ts, src/routes/proposals.ts, src/routes/vesting.ts)
After this migration, Prisma returns Decimal objects for amount, totalAmount, claimedAmount, and weight. When express.json() serializes these, Decimal objects appear as {} in the response. Only vesting.ts was updated to call .toString(). The streams route (GET /api/streams), proposals route (GET /api/proposals), treasury events route (GET /api/treasury/:addr/events), and votes route (GET /api/proposals/:id/votes) will all return broken JSON for monetary fields.

A safe approach: add a custom JSON serializer that handles Decimal, or add amount.toString() in every route that reads these fields.

No automated tests
The issue requires "Tests cover minimum, maximum, decimals, and overflow." None of these exist:

• No test for the migration preflight rejecting out-of-range values
• No test for Decimal round-trip precision through Prisma
• No test verifying JSON serialization produces exact string representations

At minimum, add an integration test that inserts and reads back a value with 7 decimal places.

Minor

@prisma/client/runtime/library deep import (src/routes/vesting.ts:1)
import { Decimal } from "@prisma/client/runtime/library" reaches into a private API path. The stable import is:

import { Prisma } from "@prisma/client";
// then use: new Prisma.Decimal(value)

The deep import works today but may break on a Prisma upgrade.

Preflight comparison uses float8 literal (prisma/migrations/.../migration.sql:15)
amount > 9.999...e28::float8 -- the float8 literal itself has limited precision. Low risk in practice since the columns are currently float8, but comparing as TEXT::NUMERIC would be more precise.

Note

This PR and PR #5 both modify the schema (this PR changes column types, PR #5 adds DeadLetterEvent model). Merge this one first, then rebase PR #5 -- the indexer currently uses parseFloat() for amount extraction which will lose precision even after Decimal migration. That needs fixing in PR #5.

[brightpixel-dev]

Thanks for the detailed review @diiabblo — all points addressed in the latest commit:

Broken routes (critical): Rather than adding .toString() to every field in every route, I set a global json replacer on the Express app in app.ts:

app.set('json replacer', (_key, value) => {
  if (value instanceof Prisma.Decimal) return value.toString();
  return value;
});

This fixes streams, treasury events, proposals, and votes in one place — any future route that returns a Decimal field gets serialisation for free.

Deep import: Replaced import { Decimal } from '@prisma/client/runtime/library' with import { Prisma } from '@prisma/client' and updated the usage to new Prisma.Decimal(progress).

Migration preflight float8 literals: Replaced all 9.999...e28::float8 comparisons with the exact '99999999999999999999999999999.9999999'::NUMERIC literal so the threshold is compared precisely rather than through an imprecise float8 cast.

Tests: Added src/__tests__/decimal-precision.test.ts using Node's built-in test runner (same pattern as the reconciliation tests in main). Covers min value, max NUMERIC(36,7) value, large-amount round-trip, Decimal.mul float-precision comparison, JSON replacer string output, null passthrough, and zero serialisation. Run with npm run test:unit.

[diiabblo]

Re-review: all fixes verified

All issues addressed cleanly:

• Global Decimal serialisation (src/app.ts): app.set("json replacer", ...) converts all Prisma.Decimal to .toFixed() across every route -- no per-route changes needed
• Tests (src/__tests__/decimal-precision.test.ts): 8 tests covering min/max/round-trip/multiplication/JSON replacer/null/zero
• Preflight precision: migration now compares against ::NUMERIC literal instead of ::float8
• vesting.ts: uses .toFixed() for exact string serialisation
• npm audit: patched path-to-regexp and qs high-severity vulns

After this merges, PR #5 needs a rebase to pick up the Decimal schema columns.