Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

feat: probabilistic failure-rate injection

Aperta
#95 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 17 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
kotlin

Direzione di ricerca

Start by reading MockConfigRepository.kt alongside the x-devview work in #A, then inspect the request flow in NetworkMockPlugin.kt and the display code in NetworkMockEndpointScreen.kt. Confirm the chosen mocked-request behavior and injectable random-source design with the issue requirements; done means parsing, per-request behavior, deterministic tests, and endpoint-screen display all work.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Part of #72

Depends on #A (the x-devview vendor extension mechanism).

Summary

Add probabilistic failure injection: an operation can be configured so that a percentage of requests to it fail, independent of which mock response is currently selected. This is a new capability — nothing in DevView supports it today, in either the bespoke JSON format or the OpenAPI-based one being built.

Why this is distinct from #88

Issue #88 ("simulate network failures") is deterministic: once a failure mode is selected for an operation, every request to it fails that way, the same way #EndpointMockState.Mock always serves the same response. This issue is probabilistic: a request to the operation independently rolls against a configured rate, so (for example) 1 in 10 requests fails and the other 9 succeed normally with whatever mock/network behavior is otherwise configured. The two are complementary, not overlapping — #88 answers "make this endpoint always fail right now", this issue answers "make this endpoint flaky, the way a real degraded service is."

Verified: this doesn't exist anywhere today

Targeted search across devview-networkmock-core and devview-networkmock-ktor for failureRate, randomFailure, probability, errorRate, and similar found zero relevant hits. EndpointConfig/Operation has no such field, EndpointMockState/OperationMockState is a two-variant sealed interface (Network/Mock) with no probabilistic concept.

What to build

  • Extend the x-devview object (from #A) with a failureRate: Double field (0.0–1.0), at the operation level (a global/document-level default may or may not make sense — recommend operation-level only for a first pass, since "some percentage of everything fails" is a much blunter tool than "this specific flaky endpoint fails sometimes").
  • When an operation has failureRate configured, each intercepted request independently rolls against it in the Ktor plugin, before the normal mock/network branching in NetworkMockPlugin.kt — regardless of whether the roll happens on a "would otherwise be mocked" or "would otherwise be live" request (decide and document which; recommend: the rate applies to mocked requests, since that's the safe, no-real-network-impact default consistent with this epic's general stance on runtime behavior — see the deferred version-forcing issue for the analogous reasoning about not touching live traffic by default).
  • Inject the random source, don't call Math.random()/platform-default directly — tests need to pin the outcome deterministically (a fake/seeded source that always "hits" or always "misses").
  • Surface failureRate in the endpoint detail screen (#79) as an additional field alongside the response-variant picker, not as a replacement for it.

Acceptance criteria

  • An operation can declare a failure rate via x-devview.failureRate.
  • The failure roll is independently evaluated per request, using an injectable random source.
  • A test with a fake random source pinned to "always fail" and one pinned to "always succeed" both behave correctly; a statistical test (many iterations, checking the observed rate is within a tolerance of the configured rate) is a reasonable addition but not a substitute for the deterministic tests.
  • The endpoint detail screen surfaces the configured failure rate (read-only display is acceptable for a first pass; in-UI editing is not required unless it fits naturally into #79's work).

Files likely touched

  • devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/repository/MockConfigRepository.kt (parsing, alongside #A)
  • devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt (the roll + injectable random source)
  • devview-networkmock/src/commonMain/kotlin/com/worldline/devview/networkmock/NetworkMockEndpointScreen.kt
Lingua principale
Kotlin
Stelle
11
Fork
3
Merge medio
10g 9h
PR unite (30g)
18

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di worldline/devview

Tutte le issue di worldline/devview

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.