Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Recover retained upscale entries from interrupted render cleanup

Aperta
  • Qualcosa non va?
#14,031 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
express, javascript, node.js
Ambito
backend, databases

Direzione di ricerca

Read server/services/musicVideo/renderCleanup.js and the pending-upscale regression first; trace how the cleanup journal and video history are serialized and published. Add recovery only for owned, present upscales, retaining journal records and bytes when writes fail or identity is uncertain. Done means the specified route or service tests cover restoration, retries, collisions, missing files, and ordinary cleanup.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area:music-video bug effort:high model:heavy plan planner:gpt-6-1-sol

Problem

An interrupted older music-video render cleanup can leave an upscale in .music-video-render-cleanup.json after its history row was removed. The retained journal record still identifies the video, but the gallery no longer advertises it. The current cleanup fix preserves and reports such entries instead of deleting their bytes; it does not restore the missing history row.

Reproduction: seed a current final render and an upscale tagged with upscaledFrom, remove the upscale's history row while retaining its journal entry and video, then inspect getRenderCleanup. The pending record is retained with a recovery reason, while the gallery history omits it. See server/services/musicVideo/renderCleanup.js and its pending-upscale regression.

Decision

Recover an owned, still-present upscale from the existing journal into video history, using the journal as the durable source of evidence. Keep the journal until the restored history entry is durably committed. Recheck under the existing serialization and backup publication boundaries; refuse conflicting IDs or filenames and preserve every file and journal record when ownership or bytes are uncertain. Do not fabricate a row for a missing file or overwrite an existing row.

Acceptance criteria

  • A pending upscale with an intact owned video and no conflicting history identity returns to the gallery with its original provenance and remains downloadable.
  • A restart or write failure at either the history or journal boundary is retryable without dropping the only recovery record or deleting video bytes.
  • Existing matching rows settle idempotently; ID/filename collisions and missing files are retained and reported clearly.
  • Route or service-boundary tests cover restoration, interrupted publication, collision, and missing-byte cases, as well as ordinary obsolete-render cleanup.

Dispatch: heavy capability and high effort are appropriate because the change crosses durable journal, history serialization, and backup consistency boundaries.

Lingua principale
JavaScript
Stelle
38
Fork
32
Merge medio
47m
PR unite (30g)
993

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di atomantic/PortOS

Tutte le issue di atomantic/PortOS

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.