Skip to content

Fail KV workloads on final errors and wrong data - #69

Draft
KirillKurdyukov wants to merge 1 commit into
masterfrom
fix/slo-kv-checks-20261014
Draft

KirillKurdyukov wants to merge 1 commit into
masterfrom
fix/slo-kv-checks-20261014

Conversation

@KirillKurdyukov

Copy link
Copy Markdown
Contributor

Changes

  • Fail all four existing Query, JDBC, Spring Data JDBC and Spring Data JPA
    workloads on an unrecovered final logical operation error, preserving its
    SDK cause through supervision and cleanup.
  • Keep one control owner with an independently retained expected generation
    and full payload. Check successful reads before advancing and after each
    acknowledged write, including during ordinary load.
  • Reserve the control key outside random traffic and use a process-private
    table for the complete create/run/drop lifecycle.
  • Normalize outgoing timestamps to storage precision before writing.
    Preserve existing schema, CLI, retry policies and load metrics.

Verification

  • Five core tests pass and all four workload modules package with JDK17.
    The runner regression exercises stale-data detection while load is active.
  • Eight original SDK source-image builds pass, without fallback images.
  • Eight real ordinary processes pass across all four adapters. Concurrent
    same-label peers keep separate tables and the longer peer survives the
    shorter peer's cleanup.
  • Sixteen real negative processes fail as expected: missing row, stale
    generation, wrong payload and a final SDK failure for each adapter.
    Data injection follows actual successful SDK read/decoding; SDK failures
    come from an independently dropped acknowledged private table.
  • Independent source-publication gate: APPROVE, no blockers.

Both SDK roles currently use the same SDK library revision, so this is
adapter/ownership verification rather than a two-version benchmark.
Recovered successful outcomes are covered at the core seam; native forced
retry recovery and hosted SLO remain unverified.

Consumer dependency

The separate ydb-java-sdk workflow PR must pin these changed examples at
68c06dfa5f09dea42613dc5eaffb0e4c456cfd51 and enforce the process verdict.
That consumer publication/CI is a follow-up, not an unchanged-master success
claim. This PR adds neither RMW nor Topic scenarios and changes no SDK library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant