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

Verify resource-bounded whole-checkout retirement under the no-archive contract

Cerrado
#13,490 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@atomantic ya está trabajando en esto.

Desde el 24/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

effort:high enhancement in-progress model:heavy plan

Problem

The ordinary held-checkout archive deliberately caps one file at 25 MiB and aggregate captured content at 250 MiB. These hardcoded defensive ceilings date to #12002; they are not user settings. A normal dependency tree can exceed both, leaving a fully delivered checkout held indefinitely. The refusal protects data, but its suggestion to preserve large outputs separately has no integrated proof-bound recovery path.

The native whole-source archive already streams complete bytes with a 20 GiB source budget, bounded manifests, exact metadata verification and a source-size-based free-space requirement. It currently requires initialized modules, so an ordinary checkout cannot legitimately use it. Initializing a module just to change eligibility is not a valid workaround.

Chosen implementation

Add an explicit operator-reviewed whole-checkout mode on macOS, reusing the existing native transaction, reservation, standalone restore, quarantine, rollback and exact-receipt protocol for checkouts with zero initialized modules. Keep the ordinary archive's existing limits unchanged. Correctly represent absent/uninitialized gitlinks without materializing them, and preserve any actual working bytes beneath them. Do not change source Git state to make a backend accept it.

Apply the existing full-source byte/manifest limits and 2 * measured source bytes + 1 GiB writable-space requirement to the new mode. Bind mode, original local inventory/incarnation, measured sources and current review proof to the journal. Preserve compatibility for existing initialized journals/archives; older readers must refuse unsupported new evidence rather than infer success. No implicit cleanup of ignored files, global limit increase or weakened hash/ownership/review guard.

Affected: scripts/lib/initialized_checkout_archive.py (currently initialized-module-required), server/services/initializedCheckoutRecovery.js, process adapter, route/validation and versioned native fixtures. Related to #13334 and the resource work in #13411.

Acceptance

  • A synthetic ordinary checkout with a large dependency file and aggregate content above the ordinary caps independently restores every byte and private Git record before supported quarantine/retirement.
  • Zero initialized modules, absent gitlinks and populated uninitialized gitlink directories retain their real original state.
  • Insufficient capacity, changing bytes/identity, active owners, nested/unknown Git stores and interrupted copy remain safe refusals with originals intact.
  • Existing ordinary caps and initialized workflows retain their contracts; exact receipts survive replay without duplicate cleanup.
  • Focused validation, required hosted CI, review and merge admission pass. No live cleanup is authorized by filing this issue.

Dispatch: model:heavy for compatible whole-checkout transaction and gitlink semantics; effort:high for preservation, rollback and failure-ordering coverage.

Lenguaje dominante
JavaScript
Estrellas
38
Forks
32
Merge medio
46 min
PR fusionados (30 d)
993

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.

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.