Add defensive normalization for variant API range values

[Copilot]

Implementation Plan: Variant Range Normalization

• Implement normalization function for malformed/empty range values
  • Add helper function to validate and normalize range JSON strings
  • Apply normalization in /api/variant/all endpoint
  • Add logging for when normalization occurs
• Create test infrastructure (if needed)
  • Set up minimal test framework consistent with the project
  • Add test for malformed range values
  • Add test for empty range values
  • Add test for valid range values
  • Add integration test simulating endpoint behavior
  • Add test documentation
• Validate implementation
  • Build the TypeScript code
  • Run tests
  • Manually verify the endpoint behavior (via integration test)
• Address code review feedback
  • Fix indentation inconsistencies
• Security and code review
  • Run code review
  • Run CodeQL security checker (0 alerts found)
• Fix CI/Build failures
  • Extract shared test utilities to avoid duplicate declarations
  • Exclude test files from TypeScript compilation
  • Verify Docker build will succeed

Original prompt

Goal

Implement backend safeguards in the variant API so that range values are always safe to parse, without changing the Prisma schema or DB data.

Context

• Repository: abhalala/fcms-server (FCMS SERVER LEGACY)
• Endpoint involved: /api/variant/all (likely in src/routes/variant.route.ts).
• Current behavior: API returns range as a string from the database. Some records have empty or malformed JSON strings, causing downstream consumers to crash when parsing (e.g., JSON.parse("") -> Unexpected end of JSON input).
• Prisma schema keeps range as String @default("{\"start\":0,\"end\":0}"). No schema changes allowed.

Requirements

1. Defensive normalization in variant fetch endpoint:
   • When returning variants, if range is falsy/empty/invalid JSON, replace it with a stringified default {"start":0,"end":0}.
   • Keep the response shape the same ({ variants: [...] }) and keep range typed as a string in the API response.
2. Logging: emit a debug/info log when a malformed/empty range is encountered and normalized; do not fail the request.
3. Tests: add/adjust a small test covering malformed/empty range to ensure normalization occurs. If no test harness exists, add a minimal test in the existing style.
4. No DB/schema migrations; code-only workaround.

Deliverables

• Code changes implementing normalization and logging.
• Tests demonstrating normalization on bad range values.
• Brief note in code comments if helpful to clarify the workaround.

This pull request was created as a result of the following prompt from Copilot chat.

Goal

Implement backend safeguards in the variant API so that range values are always safe to parse, without changing the Prisma schema or DB data.

Context

• Repository: abhalala/fcms-server (FCMS SERVER LEGACY)
• Endpoint involved: /api/variant/all (likely in src/routes/variant.route.ts).
• Current behavior: API returns range as a string from the database. Some records have empty or malformed JSON strings, causing downstream consumers to crash when parsing (e.g., JSON.parse("") -> Unexpected end of JSON input).
• Prisma schema keeps range as String @default("{\"start\":0,\"end\":0}"). No schema changes allowed.

Requirements

1. Defensive normalization in variant fetch endpoint:
   • When returning variants, if range is falsy/empty/invalid JSON, replace it with a stringified default {"start":0,"end":0}.
   • Keep the response shape the same ({ variants: [...] }) and keep range typed as a string in the API response.
2. Logging: emit a debug/info log when a malformed/empty range is encountered and normalized; do not fail the request.
3. Tests: add/adjust a small test covering malformed/empty range to ensure normalization occurs. If no test harness exists, add a minimal test in the existing style.
4. No DB/schema migrations; code-only workaround.

Deliverables

• Code changes implementing normalization and logging.
• Tests demonstrating normalization on bad range values.
• Brief note in code comments if helpful to clarify the workaround.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Note

Free review on us!

CodeRabbit is offering free reviews until Wed Dec 17 2025 to showcase some of the refinements we've made.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[abhalala]

@copilot This is not passing all the builds and tests.

[abhalala]

@copilot This is not passing all the builds and tests (github ci, docke rbuilds), fix them.

[Copilot]

@copilot This is not passing all the builds and tests (github ci, docke rbuilds), fix them.

Fixed the Docker build and GitHub CI failures. The issue was duplicate TypeScript declarations in test files causing compilation errors.

Changes made (commit 5ca9af4):

• Extracted shared test utilities into src/routes/__tests__/test-utils.ts to eliminate code duplication
• Updated both test files to import from the shared utilities
• Modified tsconfig.json to exclude __tests__ directories from compilation (tests shouldn't be compiled into the production build anyway)

The Docker build should now pass - all test-related TypeScript errors have been resolved while preserving the test functionality.

[abhalala]

Great, as long as it compiles on the gh ci builds. Commit it