Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Phase 16] S6 — Invocation-owned resources: temp state, atomic writes, worker lifetime

Abierto
  • ¿Algo no está bien?
#892 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
24/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, cli

Línea de trabajo

Start with the export_model path that builds the _merged_for_export directory and the try/finally placement around the merge, then read the atomic-write helper in forgelm/wizard/_state.py that the plan asks to promote. Also check tests/test_pipeline_orchestrator.py for the 32-writer stress pattern and the chat streamer's worker shutdown. Done means the five exit criteria pass, with a red-then-green reproducer for each unit. This spans four units across several subsystems, so it is better taken as a series of smaller issues.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

phase: 16 source: roadmap

Roadmap · Phase 16, step S6 · size M · 4 unit(s) · planned in docs/roadmap/phase-16-trust-surface-hardening.md:449-479

Summary

A resource whose lifetime belongs to one invocation is named or owned globally. export_model derives <model_path>_merged_for_export by string concatenation, adopts any pre-existing directory at that path, overwrites it and then rmtrees it while returning success=True. The try/finally opens after the merge, so when the merge raises there is no cleanup at all and a user directory has already been partly clobbered; two concurrent exports of the same model collide on the same path.

Units

Unit Tracked by (October 2026 review)
C33-EXPORT-TEMP-OWNERSHIP (= CLI-01 + GAP-01) #567 · #705
F-W20260729-TRUST-10 #551
F-W20260729-CLI-19 #691 · #706
F-W20260729-CLI-08 #567 · #691 · #705

Plan

  • One discipline throughout: allocate uniquely, bind cleanup to the handle returned at creation, and release it in finally.
  • Promote the atomic-write primitive local to forgelm/wizard/_state.py to a shared utility.
  • Keep the scratch directory in the model's parent, not the system temp dir — a merged 70B fp16 checkpoint would trade a data-loss bug for an ENOSPC bug.

Exit criteria

  • A pre-existing scratch directory containing a sentinel survives byte-identical on export success and on merge failure; two sequential exports use different scratch directories.
  • shutil.rmtree(..., ignore_errors=True) is replaced by a logged OSError.
  • The 32-concurrent-writer ingest stress pattern from tests/test_pipeline_orchestrator.py is ported and leaves no orphan temp files.
  • A mid-write exception leaves the previous deploy / quickstart destination bytes unchanged.
  • A timed-out chat streamer terminates its worker within a bounded time.

How to deliver

  • One root-cause family, committed on its own; then an Opus review round and a Sonnet review round, each with verified findings fixed and committed before the next step begins.
  • A reproducer that is red before the fix and green after; the full gauntlet from CLAUDE.md passes under ./.venv/bin/python.
  • Every English documentation edit ships with its Turkish mirror in the same commit; a new or renamed audit event gets its EN and TR catalog rows in the same PR.
  • A step that grows a deferred module carries its budget_history justification in the same diff; a widened guard rolls out non-strict first, then flips.
  • Commit bodies cite Absorbs F-W20260729-…; the CHANGELOG [Unreleased] section gets an entry only for a change a user or library consumer can observe (decision C-20).

Planned in docs/roadmap/phase-16-trust-surface-hardening.md (read at f94595f). Unit IDs (F-W20260729-…) come from the 2026-07-29/30 full-project review; the issue numbers next to them are the October 2026 review's records of the same defects.

Lenguaje dominante
Python
Estrellas
9
Forks
1
Merge medio
7 h 42 min
PR fusionados (30 d)
4

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de HodeTech/ForgeLM

Todos los issues de HodeTech/ForgeLM

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.