You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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").
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 feat: rework the NetworkMock UI for specs and versions #79's work).
devview-networkmock-ktor/src/commonMain/kotlin/com/worldline/devview/networkmock/ktor/plugin/NetworkMockPlugin.kt (the roll + injectable random source)
Part of #72
Depends on #A (the
x-devviewvendor 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-coreanddevview-networkmock-ktorforfailureRate,randomFailure,probability,errorRate, and similar found zero relevant hits.EndpointConfig/Operationhas no such field,EndpointMockState/OperationMockStateis a two-variant sealed interface (Network/Mock) with no probabilistic concept.What to build
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").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).Math.random()/platform-default directly — tests need to pin the outcome deterministically (a fake/seeded source that always "hits" or always "misses").failureRatein the endpoint detail screen (feat: rework the NetworkMock UI for specs and versions #79) as an additional field alongside the response-variant picker, not as a replacement for it.Acceptance criteria
x-devview.failureRate.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