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

Larges pushes fail, because they take too long

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
csharp, php
Área
api, backend

Línea de trabajo

Empieza por HgResumeApi.php, especialmente por el flujo de unbundle y la comprobación de isComplete; después, lee HgRunner.php y AsyncRunner.php en torno al manejo de incoming, unbundle y lockfile. Revisa la referencia de timeout de Chorus para entender la ruta de retry. Se considera terminado cuando un push grande puede reintentarse después de que la solicitud expire sin producir una excepción y el trabajo de unbundle se completa o devuelve una respuesta significativa.

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

Descripción

We recently had a push of almost 2GB (surprisingly it only took about 3 min for the client to upload it).
Here's an overview of when things broken:
image

It failed on the last chunk, because that's when the server actually starts doing the heavy lifting: trying to apply the commit.

And here's what I think/know happened:

  • Chorus sends the last chunk
    • The resumable server detects that it's the last chunk
    • It calls unbundle
    • Which calls hg incoming, which takes ~3.5m (it gets logged to /var/cache/hgresume/<transaction-ID>.bundle.incoming.async_run)
  • Because the request takes so long
  • So, presumably the PHP script gets torn down while it's waiting for the hg incoming command to finish (which does finish, because it's in its own process)
  • Because the PHP script gets torn down, no work actually happens: it never gets to running the command hg unbundle and creating a lockfile for that command (A lockfile is created for hg incoming, but that's a seperate file)
  • Because the lockfile doesn't get created, when Chorus retries the push-bundle, the server throws an Exception

Do we want to allow big pushes like this? I think so! So how:

  • It's fine if Chorus times out as long as the job actually happens and we returns a more meaningful response. The code tries to return a 200, but fails, because the lockfile it's expecting doesn't exist. The exception is good, because a missing lockfile means nothing is happening.

So we either need to:

  1. Move more stuff into an external command that doesn't get torn down 🙁
  2. Prevent the PHP script from getting torn down (e.g. move large pushes to a Lexbox Job and make sure we turn off everything that might kill a long PHP script)
  3. Make the retries smarter and have them pick up where the last one died

I think 3 sounds like the best bet. Something like:

  • Replace the exception-throwing isComplete check, with something that anticipates this senario:
    • If there's no lock file retry the unbundle
    • In the unbundle, detect if hg incoming already ran and if so:
      • Do the necessary validation
      • Then start hg unbundle
Lenguaje dominante
C#
Estrellas
0
Forks
1
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 sillsdev/hgresume

Todos los issues de sillsdev/hgresume

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.