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

go-cache-plugin: stale build object served after a source change (shared cache)

Abierto
  • ¿Algo no está bien?
#23 1 comentario 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
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
aws, go
Área
build-system, cloud

Línea de trabajo

No se nombran archivos ni tests. Empieza rastreando la construcción de la clave actionID del plugin y el manejo de outputID por parte de Get; después compara esas suposiciones con el comportamiento de la caché de cmd/go para toolchains y variantes compartidos; el trabajo estará terminado cuando se haya acordado el alcance de la corrección y haya evidencia de que el objeto obsoleto de la caché compartida ya no se sirve.

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

Descripción

Summary

Running many concurrent CI jobs against a single shared S3 cache prefix, a build occasionally compiles a package from stale source at a commit where that package's source has changed — the cache returns an object whose inputs no longer match. It surfaces as a coverage profile containing block ranges from two different revisions of the same file, and the affected job shows a ~99.9% cache-hit rate, so the stale bytes came from the cache, not a local rebuild. A manual purge of the prefix clears it; it recurs within a pipeline or two.

The failing job is only where it's detected. The same path would serve a stale object to a normal build silently, producing a binary from old source with no error — so we treat this as a correctness issue.

Questions after looking at code:

  1. The plugin keys purely on the actionID that cmd/go provides. For a cache shared across toolchains and build variants, should the key be salted with additional build context (toolchain version, cover mode, flags) — or is fully distinguishing builds considered cmd/go's responsibility, and this is really a cmd/go actionID-completeness issue rather than a plugin one?
  2. Get returns the cached object without verifying its content against the requested outputID (the comment defers content-address checking to the toolchain). Would you accept a verify-on-GET (or read-only) mode that treats a hash mismatch as a miss and rebuilds, rather than returning stale bytes? For a shared multi-writer cache that would convert a silent stale-serve into a safe miss.
    I can do the fix, if issue is accepted.
Lenguaje dominante
Go
Estrellas
81
Forks
21
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 tailscale/go-cache-plugin

Todos los issues de tailscale/go-cache-plugin

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.