mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 05:26:47 +00:00
jubnl
23c292f2f2
TripAccessGuard/TripOwnerGuard already parse :tripId exactly once (Number(), guarded by Number.isFinite) and hand the resolved TripAccess row to the handler via request[TRIP_REQUEST_KEY], TripOwnerGuard reusing TripAccessGuard's own lookup when both are on the same route rather than re-querying — verified by reading both guards directly, no change needed there. PlacesService.verifyTripAccess's own docstring separately claimed its returned `tid` gets "returned... for every downstream call to reuse (never re-parsing)" (3c's Task 9 review, L-2, carried to Plan 4). Reading every call site (not assumed) shows this is false: `.tid` has exactly one reader (PlacesController.requireTrip itself), which discards it — none of requireTrip's 13 callers read `.tid` off the trip it returns; each passes the original raw tripId string on to the write/read method it calls next, which toRowId-parses it again itself. That second parse cannot be eliminated by this gate alone: the same service methods are called directly by places.mcp.ts too, an entry point with no requireTrip gate at all (its own numeric tripId is re-stringified, String(tripId), to call them), so each method owns its own id validation regardless of entry point. Threading `tid` all the way through would mean giving every one of ~15 methods a second, number-only call shape for the REST path alone to use — a real refactor, out of this docstring fix's own scope. Corrected the docstring to say so plainly instead of repeating the false claim.