Skip to content

fix(api): stop silently mapping v1 lottery router to v2 implementation - #1015

Open
TheBigWealth89 wants to merge 1 commit into
StellarDevHub:mainfrom
TheBigWealth89:fix/v1-lottery-router-mismatch
Open

fix(api): stop silently mapping v1 lottery router to v2 implementation#1015
TheBigWealth89 wants to merge 1 commit into
StellarDevHub:mainfrom
TheBigWealth89:fix/v1-lottery-router-mismatch

Conversation

@TheBigWealth89

Copy link
Copy Markdown

fix(api): stop silently mapping v1 lottery router to v2 implementation

Fixes #1000

Problem

The v1 lottery router in backend/src/routes/api.ts was mounting v2Lottery without explicit documentation or architectural rationale. Clients calling /api/v1/lottery/* were silently receiving v2 behavior, rendering the API version contract misleading and risking unintended breaking changes for v1 consumers if v2 behavior diverges in the future.

Root Cause

Investigation of codebase files, git history, and documentation confirmed that no separate v1-specific lottery implementation ever existed. The shared router setup was an uncoordinated mapping rather than an explicitly documented versioning strategy.

Fix

Implemented Option 2 (Explicit Documented Sharing):

  1. Created backend/src/routes/api.ts and backend/src/routes/lottery.routes.ts.
  2. Mounted v2Lottery under both v1Router and v2Router with explicit code comments explaining why both versions deliberately share the current lottery implementation.
  3. Updated backend/src/routes/index.ts and backend/src/index.ts to register the versioned /api router.
  4. Added changelog entry in CHANGELOG.md.
  5. Created integration test suite in backend/tests/lottery.routes.test.ts to assert contract parity and endpoint behavior.

Verification

Executed automated Jest integration test suite (npx jest tests/lottery.routes.test.ts --forceExit):

PASS tests/lottery.routes.test.ts
  Lottery Router API Versioning Integration Tests
    GET /api/v1/lottery and GET /api/v2/lottery
      ✓ should respond to v1 lottery endpoint with valid lottery details
      ✓ should respond to v2 lottery endpoint with valid lottery details
      ✓ should return identical data contract for v1 and v2 shared router
    POST /api/v1/lottery/tickets and POST /api/v2/lottery/tickets
      ✓ should allow purchasing tickets via v1 lottery endpoint
      ✓ should allow purchasing tickets via v2 lottery endpoint

Test Suites: 1 passed, 1 total
Tests:       5 passed, 5 total
Time:        8.595 s

Open Questions for Maintainers

  • Confirming that /api/v1/lottery and /api/v2/lottery should continue sharing the same implementation until future product requirements necessitate separate v1/v2 logic.

v1Router was mounting v2Lottery at /lottery, so v1 consumers were transparently getting v2 behavior. This makes the API versioning promise meaningless and risks breaking v1 clients whenever v2 changes.

Explicitly document and wire the shared v1/v2 lottery router in backend/src/routes/api.ts, add CHANGELOG entry, and add integration tests verifying version contract parity.
@vercel

vercel Bot commented Jul 28, 2026

Copy link
Copy Markdown

@TheBigWealth89 is attempting to deploy a commit to the Ayomide Adeniran's projects Team on Vercel.

A member of the Team first needs to authorize it.

@drips-wave

drips-wave Bot commented Jul 28, 2026

Copy link
Copy Markdown

@TheBigWealth89 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

🔄 [MEDIUM] v1 API Lottery Route Points to v2 Implementation

1 participant