feat: probabilistic failure-rate injection
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- kotlin
- Domain
- frontend, networking, testing
Research direction
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.
Written by the indexing model from the issue text.
Description
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-devviewobject (from #A) with afailureRate: Doublefield (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
failureRateconfigured, each intercepted request independently rolls against it in the Ktor plugin, before the normal mock/network branching inNetworkMockPlugin.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
failureRatein 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
- Dominant language
- Kotlin
- Stars
- 10
- Forks
- 2
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 13
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from worldline/devview
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
All issues in worldline/devview
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Richie97/track-history#325 ·
-
bug CLI documentation reliability
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
KW-related Type:bug UI / UX
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
RevenueCat/purchases-android#4299 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
AAswordman/Operit#1265 · 3 comments ·