Skip to content

Renew workload-boundary authentication when the bearer changes within the same epoch #3409

Description

@shiju-nv

User Story

As an operator running a long-lived agent in a sandbox, I want the supervisor to renew its authenticated connection to the workload boundary when its bearer is refreshed, so that the workload remains usable after the original credential expires.

Problem Statement

The boundary client decides whether its cached connection needs renewed authentication by comparing credential epochs. A bearer can be refreshed without changing that epoch. The shared credential slot then contains a fresh bearer, but the existing connection has not confirmed it and remains bound to the earlier authentication lifetime. Existing streams can remain active without opening a newly authenticated boundary RPC. Frequent new TCP connections can mask the defect by authenticating new requests and extending the connection lease; a reproducer must avoid that incidental renewal.

Impact / Why This Matters

A healthy agent can become unavailable after the original control credential lifetime, interrupting active sessions despite successful credential refresh elsewhere. In the recorded integration, the original runtime failed around its 900-second credential lifetime; a reviewed local combined correction kept the same real agent process usable beyond that boundary. A fresh official-dev167 control now reproduces the defect using the supported 120-second test lifetime: the gateway renews credentials, but the boundary disconnects at the original expiry while the existing process and stream are active, followed by ControlSupervisorExited.

Acceptance Criteria

  • Replacing bearer A with bearer B within the same epoch causes the workload boundary to authenticate and confirm B.
  • The recorded credential identity belongs to the exact bearer sent on the request, even when the shared slot changes concurrently.
  • Successful same-epoch renewal preserves the physical connection and pending operations.
  • Failed confirmation does not record the replacement as accepted; a subsequent permitted retry can confirm it.
  • Epoch changes retain the authenticated recovery contract; malformed, expired and denied credentials retain failure behavior.
  • A focused regression fails against the epoch-only behavior and passes with the correction.
  • Published, checksum-identified runtime artifacts keep an unchanged real agent process usable across multiple credential lifetimes.

Reproduction Steps

  1. Use the split supervisor/workload boundary on source 7e7a8d5610f336f5f7f9f60da0951adbf295475d, the source of official dev167. Establish the boundary connection using bearer A at epoch E.
  2. Keep a boundary operation open and replace the shared bearer with valid bearer B at the same epoch E. Avoid additional boundary RPCs during the observation; data on an already open TCP/output stream is sufficient to check continuity.
  3. Allow the credential monitor to run. In the unchanged source, it compares only E and leaves the connection without a confirmation for B.
  4. Observe that the connection still depends on A's authentication lifetime. The fresh official-dev167 reproducer uses the supported 120-second gateway credential lifetime: the gateway refreshes credentials successfully, but the boundary disconnects 0.067 seconds after A expires and the sandbox enters Error with reason ControlSupervisorExited. The earlier deployed reproducer observed the same terminal condition around the original 900-second lifetime.
  5. With the correction, observe a confirmation carrying B on the same connection and verify that the previously opened operation remains usable. A separate real-runtime test must qualify behavior beyond expiry; the protocol regression alone does not emulate the full production JWT lifecycle.

Environment

  • Observed runtime: coherent OpenShell dev158, revision 292559c41c1b010de499f1d082583c1aec7b3a4a; Docker-backed split supervisor/workload on Linux x86_64.
  • Still-affected source checked: 7e7a8d5610f336f5f7f9f60da0951adbf295475d, now included in official dev167; its boundary runtime source retains the epoch-only comparison.
  • Fresh paired runtime: checksum-verified official dev167 macOS ARM64 CLI/gateway and Linux ARM64 Docker sandbox assets. The candidate changes only the source-attested supervisor and preserves the original process, established connection, epoch and runtime generation through 390.014 seconds and four renewals.

Logs

Activity

  1. added theissue type on Sep 17, 2026
  2. johntmyers commented on Sep 17, 2026

    @johntmyers
    Collaborator

    📋 triage-agent

    Closing as fixed by #3411. The boundary client now authenticates and confirms a refreshed bearer even when its credential epoch is unchanged, fingerprints the exact bearer sent, preserves the physical connection and pending operations on success, and retains retry behavior after failed confirmation. Focused regressions cover same-epoch renewal and concurrent token-slot changes.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions