Activity

1. samki6576 commented on Oct 17, 2026

   

   samki6576

   on Oct 17, 2026

   More actions

   Hi @bheemreddy-samsara this is unclaimed, and I'd like to help. Two questions before I start:

   Are you planning to implement this yourself? If so, I'll step back.

   If not would you accept a PR that does only stage 1 (wire AgentCacheContext into createFixtures in the hosted path and settle staged recordings at close), leaving the stable-identity API for a separate follow-up? That keeps the API decision with the maintainers while unblocking the cache plumbing.

   I can reproduce the current behavior first (hosted session with a file cache configured, two attempts, assert no replay) and include that in the PR description.
2. samki6576 commented on Oct 19, 2026

   

   samki6576

   on Oct 19, 2026

   More actions

   Proposed API for Stable Hosted Session Identity

   Following the closure of #1220 and the feedback from @okwasniewski, I’d like to propose a design to solve the identity problem mentioned in the issue.

   Currently, the hosted path uses testId = host:. Because attemptId is a fresh UUID, caching can't work across sessions. We need a way for the external runner (the host) to tell e2e: "This is the same logical test as last time."

   1. Proposed API Shape
      I suggest adding an optional cacheIdentity string to OpenSessionOptions (or the openHost() configuration):

   const session = await host.openSession({
     name: 'checkout-flow',
     // New: stable logical identity, scoped to the project/target by e2e
     cacheIdentity: 'tests/checkout.spec.ts::checkout-flow', 
   });

   2. How it works internally

   · Fallback: If cacheIdentity is omitted, the session falls back to the current behavior (host:), meaning no replay across sessions. This keeps it strictly opt-in and doesn't break existing external runners.
   · Key Composition: When building the cache key via buildTraceCacheKey, the testId is set to this cacheIdentity instead of the attemptId. This ensures the cache lookup finds the recording from the previous session.
   · Scoping: The cache key already includes projectId and the target's sessionIdentity, so cacheIdentity doesn't need to be globally unique—just unique within the project.

   3. Acceptance Criteria
      If this design is approved, I am ready to submit a PR that includes:

   4. Adding cacheIdentity to the public types.

   5. Wiring createAgentCacheContext into standalone-attempt.ts (using cacheIdentity for the testId and falling back to host:).

   6. Calling the settlement function correctly at close, respecting the external runner's verdict.

   7. An integration test that opens two sessions with the same cacheIdentity, records an act, and asserts it replays on the second session.

   Let me know if cacheIdentity is the preferred name, or if something like testId or logicalId fits the SDK’s naming conventions better!
3. bheemreddy-samsara commented on Oct 19, 2026

   

   bheemreddy-samsara

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Thanks @samki6576. A couple of clarifications before implementation:

   1. What do you mean by “respecting the external runner’s verdict” at close? Following the decision on Hosted sessions: accept external runner outcomes and retry metadata #1075, can this stay within the existing SDK verification/settlement semantics (settleStagedTraces), without adding an external-outcome API or treating a passing outer test as confirmation of an act? The intended proof is an act confirmed by a subsequent SDK assertion; assertions must remain live.
   2. Can you confirm that the stable logical identity is used for cache matching while unique attempt IDs and artifact-directory isolation remain unchanged, with an integration test that opens two separate hosts/sessions and observes actual replay on the second—not just equal cache keys?

   @okwasniewski, is an optional per-session cacheIdentity the preferred public shape, or would you prefer another name/existing identity mechanism? It would be helpful to agree on that before another implementation PR. The requested scope remains stable identity plus hosted cache wiring/settlement, not a new runner-outcome protocol.
4. samki6576 commented on Oct 20, 2026

   

   samki6576

   on Oct 20, 2026

   More actions

   Hi @bheemreddy-samsara, thanks for the feedback! Here are the clarifications:

   1. Respecting the external runner's verdict / Settlement semantics:
      You are completely right, and I apologize for the confusion in my previous PR. I will not add any external-outcome API or treat a passing outer test as confirmation. The settlement at close will rely strictly on the existing SDK semantics (settleStagedTraces), using the lastVerifiedStepIndex from the internal SDK assertions. The proof of a recorded act will be exactly what you described: a subsequent SDK assertion remaining live and passing.

   2. Stable identity vs. Unique attempt IDs:
      Yes, I can confirm. The unique attemptId (UUID) will remain completely unchanged for artifact directories, trace logs, and reporting. The new cacheIdentity string will be strictly injected into buildTraceCacheKey (replacing the UUID in the testId field for cache lookup only).

   And yes, the integration test will open two separate hosts/sessions with the same cacheIdentity and assert an actual replay (e.g., verifying the model isn't called the second time), not just checking that the cache keys match.

   3. Naming / API Shape:
      I'll wait for @okwasniewski's thoughts on the preferred name (cacheIdentity, logicalId, or an existing mechanism) before writing the implementation PR. I'm happy to adapt to whatever shape fits the SDK best.

   Once the name is agreed upon, I'll submit the PR with the wiring in standalone-attempt.ts and the two-session integration test. Thanks for the guidance!