Separate real-time and batch priority requests to analyze packages
I maintainer di solito rispondono entro 6 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- go
- Ambito
- distributed-systems
Direzione di ricerca
La issue nomina una coda PubSub condivisa e worker di analisi, ma non indica file né test. Inizia individuando i punti di ingresso del consumo della coda e dei worker, quindi determina come vengono identificati i messaggi batch e in tempo reale. Il lavoro è completato quando l’analisi batch non blocca più l’elaborazione in tempo reale, tramite prioritizzazione o worker separati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Go
- Stelle
- 925
- Fork
- 75
- Merge medio
- 4g 2h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ossf/package-analysis
-
Python execute phase aborts with error_analysis when the package closes stdout (MCP stdio servers)Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 78/100
ossf/package-analysis#1200 ·
I maintainer di solito rispondono entro 6 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
ossf/package-analysis#1192 ·
I maintainer di solito rispondono entro 6 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
ossf/package-analysis#1125 ·
I maintainer di solito rispondono entro 6 giorni
-
4gbAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 5/100
ossf/package-analysis#1123 ·
I maintainer di solito rispondono entro 6 giorni
-
>4 gbAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 10/100
ossf/package-analysis#1122 ·
I maintainer di solito rispondono entro 6 giorni
Tutte le issue di ossf/package-analysis
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
evener-transcript-v2-upgrade tool still scans transcript files through bufio's 4 KiB default bufferAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
prime-radiant-inc/evener#6370 ·
I maintainer di solito rispondono entro 1 giorno
-
ManageSieve proxy: a backend's NO/BYE greeting is skipped as a capability line and reported as EOFApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Mend: dependency security vulnerability
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Mend: dependency security vulnerability
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
ManageIQ/manageiq-pods#1476 ·
I maintainer di solito rispondono entro 1 giorno