Fix: complete login-code cleanup + real random-route trip generation - #9
Merged
Merged
Conversation
…tion
Addresses two issues from re-testing — fixing the real backend data
lifecycle and generation logic, not just frontend display.
Issue 1 — login codes still in the Message Center:
- Root cause: the write path was closed, but cleanup covered only exact
AUTH_SMS_CODE as a one-shot DELETE, and the cross-user operator console
(findRecent) did not exclude login codes — so historical/equivalent rows
survived in the DB or leaked through the console.
- Add LoginCodeCategories as the single source of truth (AUTH_SMS_CODE,
SMS_CODE, LOGIN_CODE, VERIFICATION_CODE). notify() rejects the whole set;
the user inbox, unread-count, AND operator-console queries all exclude it;
new idempotent, re-runnable migration V5 purges every login-code row.
- Add DemoSmsProviderTest: the demo provider's only collaborator is the
login-code store — structurally it can never reach notification-service.
Issue 2 — random route generated no usable carpool trips:
- Root causes: no same-city constraint (picked pairs across 4 cities), no
distance-range validation / retry / max-attempts, departures outside the
search window, and the frontend never adopted the generated route so the
real trip-search never ran for its endpoints.
- Add trip.demo.* config (min/max/preferred distance, maxAttempts, offers,
departure lead/spread, retention). Rewrite generateRandom: same-city POIs
→ authoritative map-service quote → accept only within [min,max] (prefer
the tighter band) → retry other pairs → 422 DEMO_NO_VALID_ROUTE if none.
Departures now fall inside the matching window. Endpoints return an
envelope {origin,destination,route,offers}; the frontend adopts the route
so the NORMAL trip-search returns the persisted demo trips (no fabricated
cards). Prices stay strictly PricingPolicy-derived.
Tests: backend 363 green (15 modules); Playwright 17 passed incl. new
demo-flow.spec (Message Center has no login code; random route in-range and
surfaced via real search). scripts/verify.sh fully green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #8 (merged). Fixes two issues found on re-testing, at the real backend data-lifecycle level — not just frontend display.
Issue 1 — login verification codes still appeared in the Message Center
Root cause: the write path was already closed, but cleanup covered only exact
AUTH_SMS_CODEas a one-shotDELETE, and the cross-user operator console (findRecent) did not exclude login codes — so historical/equivalent rows survived in the DB or leaked through the console.Fix:
LoginCodeCategories— single source of truth (AUTH_SMS_CODE,SMS_CODE,LOGIN_CODE,VERIFICATION_CODE).notify()rejects the whole set; the user inbox, unread-count, and operator-console queries all exclude it.V5__purge_all_login_code_deliveries.sqlpurges every login-code row (safe to run more than once, touches no business notification).DemoSmsProviderTest— structural guard that the demo provider's only collaborator is the login-code store, so a code can never reach notification-service.Issue 2 — random route generated no usable carpool trips
Root causes: no same-city constraint (pairs picked across 4 fixture cities), no distance-range validation / retry / max-attempts, departures outside the search window, and the frontend never adopted the generated route so the real
trip-searchnever ran for its endpoints.Fix:
trip.demo.*config: min/max/preferred distance (default 2/30 km, preferred 5–20 km),max-attempts(25),offers(5), departure lead/spread (≤ matching window), retention (24 h).generateRandom: same-city POIs → authoritative map-service quote → accept only within[min,max](preferring the tighter band) → retry other pairs →422 DEMO_NO_VALID_ROUTEif none qualifies. Distance comes only from the authoritative route.{origin, destination, route, offers}; the frontend adopts the route as the active selection so the normalGET /api/trips/searchreturns the persisted demo trips — no fabricated cards. Prices stay strictlyPricingPolicy-derived.Tests
./mvnw test→ 363 tests, 0 failures (15 modules).demo-flow.spec.ts: (1) Message Center shows a business notice and no verification-code text; (2) random route → matching demo trips appear via the real search list with in-range distance../scripts/verify.shfully green.Not run here (unchanged, environment-limited): full-stack
scripts/demo-smoke.sh(needs the Docker stack) and the staging-only SSE load test.🤖 Generated with Claude Code