Skip to content

feat: probabilistic failure-rate injection #95

Description

@MaxMichel2

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 (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

  • 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).

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions