| Metadata | Value |
|---|---|
| Status | Active |
| Version | 1.0.0 |
| Last Updated | 2026-09-10 |
| Author | Sangeetha Grantha Team |
| Document Type | Evidence record |
[!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.
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.
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.
println instead of loggerCanonicalExtractionDto first, fall back to ScrapedKrithiMetadatapersistFromCanonical() method mapping canonical sections/variants to DBprintln error handler with logger.errorignoreUnknownKeys = true) for forward compatibilityPOST /v1/admin/imports/backfill-lyrics| File | Change |
|---|---|
modules/backend/api/.../services/LyricVariantPersistenceService.kt |
Dual-format detection, persistFromCanonical(), proper logging |
modules/backend/api/.../routes/ImportRoutes.kt |
Backfill endpoint |
agastISvaraM) had empty sections in extraction payload — needs re-extraction, not backfillagastISvaraM, allakallOlamu) had no section markers — assigned single OTHER section with full textRef: application_documentation/10-implementations/track-094-lyric-persistence-fix-backfill.md