Creating a ride from the hub had two integrity problems:
- The "Created … success" toast fired optimistically before the Firestore write, and a
commit failure was only console.error'd — so a user could be told the ride was created
when nothing persisted (the ride would then vanish on the next snapshot).
- Every created ride wrote a hardcoded meetingPoint at 34.5378, -83.9849 (Helen, GA)
regardless of the typed location — fabricated GPS attached to real rides.
Fixes:
- Report success only after `batch.commit()` resolves; on failure, roll back the optimistic
insert and show an error. When there is no authenticated session / Firestore, keep the
local entry for responsiveness but make no cloud-success claim.
- Extract buildWebGroupRidePayload (pure): stores the rally point as displayName/address
text and omits latitude/longitude (the web form has no map picker / geocoder, so we never
fabricate coordinates). mapFirestoreRideToSummary already treats a missing coordinate as
"not pinned yet".
Join-by-code, join/leave, edit, and delete flows were reviewed and persist/authorize
correctly; no changes needed there.
Tests: buildWebGroupRidePayload asserts no fabricated lat/lon, rally-point text/fallback,
authoritative organizer/access fields, scheduled-time handling, and club identity. Existing
group-ride UI tests remain green.
Known limitation: true address autocomplete and automatic route-distance calculation require
a geocoding/routing API that does not exist in this codebase; distance and rally point remain
free-text until that backend lands.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6956e809a3