Race condition between TargetIn event in StepRunner and events emission in TestStep
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- go
- Ambito
- testing-qa
Direzione di ricerca
Inizia da pkg/runner/step_runner.go intorno alla riga 193 e segui come StepRunner invia i targets attraverso il suo canale di input, come TestStep emette gli eventi e come outputLoop gestisce i risultati. Riproduci o analizza la race condition nell’ordine tra EventTargetIn e TargetOut o TargetError, quindi definisci un approccio di sincronizzazione che preservi l’ordine degli eventi richiesto e verificalo con la suite di test esistente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The problem raises as we can't atomicly (at least without "ugly" locks in events emission) pass the target to the test step via channel and emit EventTargetIn event.
Currently we are having the following partial work-around:
https://github.com/linuxboot/contest/blob/main/pkg/runner/step_runner.go#L193
// put the target into step runner
case sr.input <- tgt:
// by the time we are hare, the test step could have already processed the target and emitted 100500 events
// test steps rarely emit events, so it is not a big issue. For consistency with TargetOut or TargetError I made this hack:
// we should always emit TargetIn before TargetOut or TargetError
// we have a race condition that outputLoop may receive result for this target first
// in that case we will emit TargetIn in outputLoop and should not emit it here
sr.mu.Lock()
if targetInfo.acquireTargetInEmission() {
if err := emitEvent(ctx, ev, target.EventTargetIn, tgt, nil); err != nil {
sr.setErrLocked(ctx, fmt.Errorf("failed to report target injection: %w", err))
}
}
sr.mu.Unlock()
- Lingua principale
- Go
- Stelle
- 20
- Fork
- 17
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un 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 linuxboot/contest
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
-
update readmeForse già presa @mimir-d l’ha presa 1253 giorni fa. Apertabug documentation
-
enhancement good first issue
Difficoltà 3/5 1-2 giorni Idoneità per principianti 38/100
-
enhancement good first issue v2_overhaul
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
enhancement good first issue
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
Tutte le issue di linuxboot/contest
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue load-balancing
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ktrubilo9/edge-proxy#53 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
[receiver/dockerstats] ContainerEnvToMap truncates environment variable values containing "="Apertabug needs triage receiver/dockerstats
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
open-telemetry/opentelemetry-collector-contrib#51948 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
LanternOps/breeze#8353 ·
I maintainer di solito rispondono entro 1 giorno