Sangeetha-Grantha

Metadata Value
Status Active
Version 1.0.0
Last Updated 2026-09-10
Author Sangeetha Grantha Team
Document Type Evidence record

Lyric Persistence Fix & Backfill


[!NOTE] Historical evidence: results, counts, commands, and observations below belong to the original work described here. The editorial update date is not a new test or corpus verification. For present behavior, use current feature map.

Purpose

Fix the lyric variant persistence pipeline so that krithis imported via the Python extraction worker (CanonicalExtractionDto format) have their lyrics, sections, and lyric sections saved to the database. Backfill the 67 already-approved krithis from TRACK-093 that were approved with zero lyrics persisted.

Root Cause

A classic integration seam failure: ExtractionResultProcessor stores CanonicalExtractionDto in parsed_payload, but LyricVariantPersistenceService only knew ScrapedKrithiMetadata. The deserialization mismatch was swallowed by a catch(e) { println(...) } block — no logger, no API error, no status change.

Why It Was Invisible

  1. Silent catch with println instead of logger
  2. No assertion at approval time that lyrics were actually persisted
  3. No integration test covering the full pipeline
  4. UI showed “Approved” with no indication lyrics were missing

Implementation Details

Code Changes

File Change
modules/backend/api/.../services/LyricVariantPersistenceService.kt Dual-format detection, persistFromCanonical(), proper logging
modules/backend/api/.../routes/ImportRoutes.kt Backfill endpoint

Results

Ref: application_documentation/10-implementations/track-094-lyric-persistence-fix-backfill.md


Section index · Documentation home · Feature status