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

q2 render should take a lockfile in the output directory so two concurrent renders cannot interleave their writes

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
build-system

Línea de trabajo

Start by locating the q2 render and q2 preview render entry points and how they determine the output directory; the issue does not name files or tests. Then trace render lifecycle and signal handling to see where a lock can be acquired and released. Done means concurrent renders are rejected with a useful diagnostic, stale locks do not block rendering, and preview holds the lock only during rendering.

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

Descripción

Summary

Two renders of the same project can run at the same time and write the same output directory: a q2 preview --static that re-renders on file changes, and a q2 render started by hand (or by an editor task, a CI step, a second terminal). Nothing stops the second one, and the two interleave their writes. Proposal: q2 render takes a lockfile in the output directory for the duration of a render and steps back, with a diagnostic, when another render already holds it. Quarto 1 never did this; it is cheap and catches the easy mistakes.

What happened

A website project was being served with q2 preview --static, which watches the project and re-renders it when a source file changes. While it was running, I edited _quarto.yml and ran q2 render in another terminal. Both renders ran at once into _site/.

The render completed without diagnostics, but the search index was broken afterwards:

  • site_libs/quarto-search/pagefind/pagefind-entry.json named an index hash (en_3a8a4314f7),
  • the matching pagefind.en_3a8a4314f7.pf_meta file was missing from the directory,
  • in the browser, every query returned "No results", with Failed to load the meta index: Error: invalid gzip data and Pagefind: WASM Error (No pointer) on the console (the server answered the missing file with a 404 text body, which the runtime tried to gunzip).

Stopping the preview and rendering once more fixed it. I could not reproduce the missing file with a single renderer, with or without incremental renders, so the cause is the interleaving: one render's search-index step wrote its files while the other was replacing the directory.

The search index is just the piece that broke visibly. Any whole-directory output (site_libs/, the Pagefind index, llms-full.txt, alias redirects) is open to the same interleaving, and the symptoms are confusing because the final log line of each render says it succeeded.

Proposal

  • When a render starts, create a lockfile in the output directory (for example _site/.quarto-render.lock, or next to the other render bookkeeping under .quarto/). Write the pid, the start time, and the command that holds it.
  • If the lock exists and its holder is alive, do not render. Emit a diagnostic naming the holder ("another render of this project is running: q2 preview pid 12345, started 10:57:03") and exit non-zero. A --wait flag or a short bounded wait before giving up would cover the common case of a preview mid-render.
  • If the lock exists but its pid is gone, treat it as stale: remove it, say so, and continue. A crash must not wedge the project.
  • q2 preview holds the lock only while it is actually rendering, not while it is merely serving and watching, so a manual render between edits still works when the preview is idle.
  • Release the lock on success, failure, and signal.

Races remain possible (two renders starting in the same instant, network file systems, lock files are not transactions), and that is acceptable. The goal is that the obvious mistake, a hand-run render against a watched project, fails loudly instead of corrupting the output silently.

Environment

q2 0.35.0-nightly.20261021, macOS.

Lenguaje dominante
Rust
Estrellas
278
Forks
19
Merge medio
20 h 23 min
PR fusionados (30 d)
164

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 quarto-dev/q2

Todos los issues de quarto-dev/q2

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.