GCP log wrt request preconditions
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
- 15/100
Línea de trabajo
Start by reading PR #70 for the tile write case and PR #61 for the checkpoint write case, then compare their request-precondition handling with the behavior described here. Confirm whether any work remains beyond those implementations, including the need to retry a failed Integrate step in Cloud Build; the issue does not name files or tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The GCP log implementation uses request preconditions to address race conditions.
Case 1:
Tile write failure: implemented in https://github.com/transparency-dev/serverless-log/pull/70.
Entries have been sequenced successfully, but when Integrate runs, writing a tile (partial or full) somehow results in a tile that is different that the one that has already been written. This should not happen.
Case 2:
Checkpoint write failure: implemented in https://github.com/transparency-dev/serverless-log/pull/61.
If there is a race condition in Integrate, one run will fail because the checkpoint will have changed by the time it wants to write its version of the checkpoint. This may happen in race conditions. Since Integrate is idempotent, you just need to invoke the Cloud Function again.
If you are invoking the functions from Cloud Build (as we are in the Armored Witness project), the log operator will need to manually retry the Integrate step of the Cloud Build config that failed OR the log will not be updated until the next time an entry gets added and Sequence and Integrate are invoked. It is okay for the latter to happen wrt integrity of the log; the only consequence is that the log will not include the failed run's entry until the next Integrate call.
- Lenguaje dominante
- Go
- Estrellas
- 9
- Forks
- 7
- Merge medio
- 4 h 13 min
- PR fusionados (30 d)
- 7
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
open-telemetry/opentelemetry-go-compile-instrumentation#1467 ·
Los mantenedores suelen responder en 3 días
-
Python 3.15 supportPosiblemente ocupada @amnesiaof la tomó hoy. AbiertoL: python L: python:uv
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
dependabot/dependabot-core#16524 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
duplication
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
openvibely/openvibely#1443 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
canonical/service-mesh#845 ·
Los mantenedores suelen responder en 1 día