Skip to content

test(kubernetes): cover stale gateway stop views and define operation condition semantics #5288

Open

Description

@matthewgrossman

User Story

I run OpenShell's Kubernetes conformance tests and maintain its lifecycle coverage. After fixing #5195 in #5196, I need the remaining review observations captured so stale gateway views and future driver operations cannot silently receive incorrect lifecycle meaning.

Description

Follow up on Evan's review of #5196. These were non-blocking observations, not a demonstrated regression in the merged fix.

  1. Stale gateway view during stop. Mid-stop Kubernetes snapshots now report Ready=False with DependenciesNotReady, rather than Bootstrapping=True. They carry no explicit operation-in-progress signal. The gateway test added in fix(kubernetes): keep a late stop snapshot from reviving a stopped sandbox #5196 covers a gateway already in Stopping, but not a stale view such as one still reporting Running. Establish the expected behavior and add deterministic coverage for that case, including eventual convergence after stop completes.
  2. Operation and generation semantics. sandbox_from_object_with_bootstrap_state treats only stop specially; other operation values are interpreted as starting. Define how supported, missing, unknown and future operation values should map to sandbox conditions. Clarify how operation identity and runtime generation affect whether a delayed snapshot can advance or regress the gateway's view. Do not assume an arbitrary future operation is a start without an explicit contract.

Investigate the current behavior before choosing a fix. Preserve genuine start/restart recovery from a stale gateway view while ensuring stop observations do not imply a new start. Keep any wider protocol or generation redesign separately scoped if it is required; this issue should establish the contract and tests, not prescribe a new condition field in advance.

Context

Definition of Done

  • Document the expected gateway behavior when a stale Running view receives a mid-stop snapshot, and how it converges after stop completion.
  • Add deterministic tests for that stale-view case and delayed stop snapshots, without relying on timing loops.
  • Define and test condition mapping for supported operations and missing/unknown operation values; future operations require deliberate routing.
  • Clarify the operation/generation assumptions used to accept or reject stale snapshots, identifying any separately scoped design work.
  • Preserve the bug(kubernetes): stopped sandbox regresses to Provisioning after stop completes #5195 regression coverage and genuine start/restart recovery from stale gateway views.
  • If investigation finds incorrect behavior, fix it with a regression test; otherwise record the verified behavior and remaining contract limits.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions