Skip to content

e2e: stop TestGracefulWorkerTerminationSuspend racing the actor to CRASHED - #1019

Closed
Benjamin Elder (BenTheElder) wants to merge 1 commit into
agent-substrate:mainfrom
BenTheElder:e2e-fix-graceful-suspend-race
Closed

e2e: stop TestGracefulWorkerTerminationSuspend racing the actor to CRASHED#1019
Benjamin Elder (BenTheElder) wants to merge 1 commit into
agent-substrate:mainfrom
BenTheElder:e2e-fix-graceful-suspend-race

Conversation

@BenTheElder

Copy link
Copy Markdown
Collaborator

The test deletes the worker pod, sleeps a fixed 2s, then suspends the actor, which is meant to land while the graceful shutdown is under way. On micro-VM it lands after the actor has already reached CRASHED, so the suspend is rejected and the test fails on every run since #893 enabled it there - on main as well as on unrelated PRs:

termination_test.go: failed to suspend Actor: rpc error: code = FailedPrecondition desc = MarkSuspending prerequisite not met for Actor: demo/graceful-term-suspend-... (got: STATUS_CRASHED, want STATUS_RUNNING or STATUS_PAUSED)

This PR updates the test to poll for STATE_DRAINING instead of a fixed sleep.

Fixes #1016

It's a good idea to open an issue first for discussion.

  • Tests pass
  • Appropriate changes to documentation are included in the PR

…ASHED

The test deletes the worker pod, sleeps a fixed 2s, then suspends the actor,
which is meant to land while the graceful shutdown is under way. On micro-VM it
lands after the actor has already reached CRASHED, so the suspend is rejected
and the test fails on every run since agent-substrate#893 enabled it there - on main as well as
on unrelated PRs:

  termination_test.go: failed to suspend Actor: rpc error:
  code = FailedPrecondition desc = MarkSuspending prerequisite not met for
  Actor: demo/graceful-term-suspend-... (got: STATUS_CRASHED, want
  STATUS_RUNNING or STATUS_PAUSED)

A duration is the wrong thing to wait on: how quickly the drain starts, and how
long the actor survives it, differ by sandbox class. Wait for the state the test
actually depends on instead - the control plane marking the worker DRAINING when
it sees the pod's DeletionTimestamp - and suspend as soon as that is observable
rather than 2s later.

Measured against a kind cluster running this branch's main, micro-VM demo:

  before   0/3 pass, every failure the MarkSuspending rejection above
  after   14/15 pass; the one failure was elsewhere in the test (a resume
          readyz timeout, the pre-existing flake) and never the suspend

The three termination tests also pass together, twice, with no skips.

This keeps what the test is for. ateom's graceful shutdown deliberately releases
its lock so 'a suspend arriving mid-drain' is still served, and that is what is
being exercised; only the way the test finds that window changes.
@BenTheElder

Copy link
Copy Markdown
Collaborator Author

/hold

so while we should avoid fixed timeouts, and tests are passing locally with this change where they failed before it, this doesn't make sense. it should stay crashed.

@BenTheElder

Copy link
Copy Markdown
Collaborator Author

focusing on fixing the mechanism in ateom

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.

TestGracefulWorkerTerminationSuspend failing on main

1 participant