Separate real-time and batch priority requests to analyze packages
Los mantenedores suelen responder en 6 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- go
- Área
- distributed-systems
Línea de trabajo
El issue menciona una cola PubSub compartida y workers de análisis, pero no indica archivos ni tests. Empieza localizando los puntos de entrada del consumo de la cola y de los workers; después determina cómo se identifican los mensajes por lotes y en tiempo real. La tarea estará terminada cuando el análisis por lotes ya no bloquee el trabajo en tiempo real, mediante priorización o workers separados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I started a backfill of 95k packages from crates.io.
These enter as messages in the same PubSub queue as the live "real-time" messages for packages being updated.
Unfortunately this causes the "real-time" requests to be delayed, potentially missing detections for packages that are only live for a short time on a package repository.
Ideally there should be a way to priotize "batch" messages from "real-time" messages, so the real-time messages can be processed first (or at a higher rate).
Alternatively separate "batch" analysis workers could be spun-up when batch work is present.
Either way it would be good if batch work didn't block real-time work.
- Lenguaje dominante
- Go
- Estrellas
- 925
- Forks
- 75
- Merge medio
- 4 d 2 h
- PR fusionados (30 d)
- 3
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.
Más de ossf/package-analysis
-
Python execute phase aborts with error_analysis when the package closes stdout (MCP stdio servers)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
ossf/package-analysis#1200 ·
Los mantenedores suelen responder en 6 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ossf/package-analysis#1192 ·
Los mantenedores suelen responder en 6 días
-
OpenSSF Documentation UpdatesAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
ossf/package-analysis#1125 ·
Los mantenedores suelen responder en 6 días
-
4gbAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 5/100
ossf/package-analysis#1123 ·
Los mantenedores suelen responder en 6 días
-
>4 gbAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 10/100
ossf/package-analysis#1122 ·
Los mantenedores suelen responder en 6 días
Todos los issues de ossf/package-analysis
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
evener-transcript-v2-upgrade tool still scans transcript files through bufio's 4 KiB default bufferAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
prime-radiant-inc/evener#6370 ·
Los mantenedores suelen responder en 1 día
-
ManageSieve proxy: a backend's NO/BYE greeting is skipped as a capability line and reported as EOFAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Mend: dependency security vulnerability
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Mend: dependency security vulnerability
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
ManageIQ/manageiq-pods#1476 ·
Los mantenedores suelen responder en 1 día