Skip to content

CI Failure: harness-custom-jwt E2E rejects-SigV4 test fails with 403 missing audience claim #1623

Description

@aidandaly24

Summary

The new e2e-tests/harness-custom-jwt.test.ts (added in #1609) fails on the full-suite E2E run, shard 2/5.

Root cause

The test fixture is misconfigured, surfaced by the harness auto-fetch flow that landed in the main+preview merge (#1598, #1611):

  1. The harness is deployed with --allowed-audience <clientId>, so the service validates the token's aud claim.
  2. The test authenticates via Cognito client_credentials (M2M), whose tokens carry a client_id claim and no aud.
  3. The fixture also registers a managed OAuth credential (--client-id/--client-secret), so a default invoke (no --bearer-token) now auto-fetches a JWT instead of doing SigV4 (canFetchHarnessToken() → true).
  4. The service rejects the fetched token: 403 \"*** missing required audience claim.\" — which doesn't match the test's expected client-side customJWTRejectMsgRegex.

The sibling byo-custom-jwt.test.ts passes only because it patches agentcore.json with no credential, so it hits the client-side SigV4 fast-fail the regex expects. The same aud misconfiguration is latent there, hidden by a weak not.toMatch assertion.

Fix

  • Use --allowed-clients (matches the client_id claim Cognito M2M tokens carry) instead of --allowed-audience.
  • Update the deploy assertion to check AllowedClients.
  • Reframe the invoke tests to assert the real post-merge behavior (default invoke auto-fetches a JWT and is accepted; bearer-token invoke returns exitCode 0).

This is a test-only fix — no shippable CLI behavior changes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingci

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions