Skip to content

fix: observability cleanup uses wrong API parameter name for endpoint deletion - #2008

Open
jyotsnamas wants to merge 2 commits into
awslabs:mainfrom
jyotsnamas:fix/observability-cleanup-params
Open

fix: observability cleanup uses wrong API parameter name for endpoint deletion#2008
jyotsnamas wants to merge 2 commits into
awslabs:mainfrom
jyotsnamas:fix/observability-cleanup-params

Conversation

@jyotsnamas

Copy link
Copy Markdown
Contributor

Summary

  • Fix 04-observability-with-strands/cleanup.py which uses name= instead of endpointName= in the delete_agent_runtime_endpoint() call
  • Also skip DEFAULT endpoints (auto-managed, cannot be explicitly deleted)
  • This is a distinct bug from the general DEFAULT endpoint issue — even non-DEFAULT endpoints would fail to delete due to the wrong parameter name

Root cause

# BROKEN (line 52):
control.delete_agent_runtime_endpoint(agentRuntimeId=runtime_id, name=ep_name)

# FIXED:
control.delete_agent_runtime_endpoint(agentRuntimeId=runtime_id, endpointName=ep_name)

boto3 error:

Parameter validation failed:
Missing required parameter in input: "endpointName"
Unknown parameter in input: "name", must be one of: agentRuntimeId, endpointName, clientToken

Verification

Deployed 04-observability-with-strands to AgentCore Runtime in us-west-2:

  • Without fix: Cleanup prints boto3 parameter validation error, runtime leaked
  • With fix: Endpoint deleted, runtime deleted, confirmed gone via list-agent-runtimes

Test plan

  • Deploy observability module, run original cleanup → parameter validation error, runtime leaked
  • Run fixed cleanup → endpoint and runtime successfully deleted
  • Confirmed via aws bedrock-agentcore-control list-agent-runtimes — runtime gone

🤖 Generated with Claude Code

…DEFAULT endpoint

The delete_agent_runtime_endpoint() call used `name=` instead of the correct
`endpointName=` parameter, causing silent failure. Also skip DEFAULT endpoints
which are auto-managed by the API and cannot be explicitly deleted.

Discovered during live AWS deployment testing (V2 pass).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Latest scan for commit: 4895a18 | Updated: 2026-08-31 16:06:44 UTC

Security Scan Results

Scan Metadata

  • Project: ASH
  • Scan executed: 2026-08-31T16:03:44+00:00
  • ASH version: 3.0.0

Summary

Scanner Results

The table below shows findings by scanner, with status based on severity thresholds and dependencies:

Column Explanations:

Severity Levels (S/C/H/M/L/I):

  • Suppressed (S): Security findings that have been explicitly suppressed/ignored and don't affect the scanner's pass/fail status
  • Critical (C): The most severe security vulnerabilities requiring immediate remediation (e.g., SQL injection, remote code execution)
  • High (H): Serious security vulnerabilities that should be addressed promptly (e.g., authentication bypasses, privilege escalation)
  • Medium (M): Moderate security risks that should be addressed in normal development cycles (e.g., weak encryption, input validation issues)
  • Low (L): Minor security concerns with limited impact (e.g., information disclosure, weak recommendations)
  • Info (I): Informational findings for awareness with minimal security risk (e.g., code quality suggestions, best practice recommendations)

Other Columns:

  • Time: Duration taken by each scanner to complete its analysis
  • Action: Total number of actionable findings at or above the configured severity threshold that require attention

Scanner Results:

  • PASSED: Scanner found no security issues at or above the configured severity threshold - code is clean for this scanner
  • FAILED: Scanner found security vulnerabilities at or above the threshold that require attention and remediation
  • MISSING: Scanner could not run because required dependencies/tools are not installed or available
  • SKIPPED: Scanner was intentionally disabled or excluded from this scan
  • ERROR: Scanner encountered an execution error and could not complete successfully

Severity Thresholds (Thresh Column):

  • CRITICAL: Only Critical severity findings cause scanner to fail
  • HIGH: High and Critical severity findings cause scanner to fail
  • MEDIUM (MED): Medium, High, and Critical severity findings cause scanner to fail
  • LOW: Low, Medium, High, and Critical severity findings cause scanner to fail
  • ALL: Any finding of any severity level causes scanner to fail

Threshold Source: Values in parentheses indicate where the threshold is configured:

  • (g) = global: Set in the global_settings section of ASH configuration
  • (c) = config: Set in the individual scanner configuration section
  • (s) = scanner: Default threshold built into the scanner itself

Statistics calculation:

  • All statistics are calculated from the final aggregated SARIF report
  • Suppressed findings are counted separately and do not contribute to actionable findings
  • Scanner status is determined by comparing actionable findings to the threshold
Scanner S C H M L I Time Action Result Thresh
bandit 0 0 0 0 0 0 799ms 0 PASSED MED (g)
cdk-nag 0 0 0 0 0 0 5.8s 0 PASSED MED (g)
cfn-nag 0 0 0 0 0 0 10ms 0 PASSED MED (g)
checkov 0 0 0 0 0 0 5.0s 0 PASSED MED (g)
detect-secrets 0 0 0 0 0 0 705ms 0 PASSED MED (g)
grype 0 0 0 0 0 0 58.7s 0 PASSED MED (g)
npm-audit 0 0 0 0 0 0 188ms 0 PASSED MED (g)
opengrep 0 0 0 0 0 0 <1ms 0 SKIPPED MED (g)
semgrep 0 0 0 0 0 0 <1ms 0 MISSING MED (g)
syft 0 0 0 0 0 0 2.1s 0 PASSED MED (g)

Replace `except Exception` with `except ClientError` to fix BLE001.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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.

1 participant