fix: fuel-logs enhanced repository methods return raw rows without mapping, breaking numeric type contract #244

New Issue

egullickson · 2026-05-16T02:07:25Z

egullickson commented

2026-05-16 02:07:25 +00:00

Summary

Per the audit performed for #241, the "enhanced" methods in backend/src/features/fuel-logs/data/fuel-logs.repository.ts (createEnhanced, findByVehicleIdEnhanced, updateEnhanced) return raw pg rows instead of going through mapRow. The legacy mapRow correctly coerces all decimal fields with parseFloat, but the enhanced path bypasses it.

Affected Fields (enhanced methods only)

Returned as strings instead of numbers:

fuelUnits — DECIMAL(8,3)
costPerUnit — DECIMAL(6,3)
tripDistance — DECIMAL(10,3)

(Other legacy fields like totalCost, gallons, pricePerGallon are not affected because the legacy mapRow coerces them.)

Investigation Required (before fixing)

Which API endpoints invoke createEnhanced / findByVehicleIdEnhanced / updateEnhanced vs. the legacy methods? (Look for "enhanced" in route handlers.)
What does the frontend do with these fields? If it already calls Number() defensively (e.g. fuel-logs hooks or analytics components), fixing the mapper will make those redundant.
Are there any internal callers (e.g. statistics aggregations, exports) that compute arithmetic on these fields? Those will be silently broken right now ("3.5" + "1.2" = "3.51.2" in JS).

Suggested Fix

Add a mapper for the enhanced shape (or extend the legacy mapRow) that coerces all decimal fields with parseFloat or Number(). Route all three enhanced methods through it.

Acceptance Criteria

Audit every call site of the enhanced methods and the consumers of their return values.
Decide whether to extend the existing mapRow or add a sibling mapEnhancedRow.
Replace raw row returns in createEnhanced, findByVehicleIdEnhanced, updateEnhanced with the mapper.
Remove any defensive Number() calls in consumers that become unnecessary.
Check whether internal arithmetic (totals, statistics) was relying on broken behavior. If so, fix the arithmetic too.
Mobile + desktop verification of UI surfaces using these fields.
Linting, type-check, and tests pass.

#241 / PR #242 — fixed the same pattern in maintenance and ownership-costs (which used the simple mapper approach).

## Summary Per the audit performed for #241, the "enhanced" methods in `backend/src/features/fuel-logs/data/fuel-logs.repository.ts` (`createEnhanced`, `findByVehicleIdEnhanced`, `updateEnhanced`) return raw pg rows instead of going through `mapRow`. The legacy `mapRow` correctly coerces all decimal fields with `parseFloat`, but the enhanced path bypasses it. ## Affected Fields (enhanced methods only) Returned as strings instead of numbers: - `fuelUnits` — `DECIMAL(8,3)` - `costPerUnit` — `DECIMAL(6,3)` - `tripDistance` — `DECIMAL(10,3)` (Other legacy fields like `totalCost`, `gallons`, `pricePerGallon` are not affected because the legacy `mapRow` coerces them.) ## Investigation Required (before fixing) - Which API endpoints invoke `createEnhanced` / `findByVehicleIdEnhanced` / `updateEnhanced` vs. the legacy methods? (Look for "enhanced" in route handlers.) - What does the frontend do with these fields? If it already calls `Number()` defensively (e.g. fuel-logs hooks or analytics components), fixing the mapper will make those redundant. - Are there any internal callers (e.g. statistics aggregations, exports) that compute arithmetic on these fields? Those will be silently broken right now (`"3.5" + "1.2"` = `"3.51.2"` in JS). ## Suggested Fix Add a mapper for the enhanced shape (or extend the legacy `mapRow`) that coerces all decimal fields with `parseFloat` or `Number()`. Route all three enhanced methods through it. ## Acceptance Criteria - [ ] Audit every call site of the enhanced methods and the consumers of their return values. - [ ] Decide whether to extend the existing `mapRow` or add a sibling `mapEnhancedRow`. - [ ] Replace raw row returns in `createEnhanced`, `findByVehicleIdEnhanced`, `updateEnhanced` with the mapper. - [ ] Remove any defensive `Number()` calls in consumers that become unnecessary. - [ ] Check whether internal arithmetic (totals, statistics) was relying on broken behavior. If so, fix the arithmetic too. - [ ] Mobile + desktop verification of UI surfaces using these fields. - [ ] Linting, type-check, and tests pass. ## Related - #241 / PR #242 — fixed the same pattern in maintenance and ownership-costs (which used the simple mapper approach).

egullickson added the

labels 2026-05-16 02:07:30 +00:00

egullickson added

and removed