Skip to content

CloudTrail: Fix start_logging/stop_logging to accept trail ARN - #10131

Open
Mide69 wants to merge 1 commit into
getmoto:masterfrom
Mide69:fix/cloudtrail-start-stop-logging-arn
Open

CloudTrail: Fix start_logging/stop_logging to accept trail ARN#10131
Mide69 wants to merge 1 commit into
getmoto:masterfrom
Mide69:fix/cloudtrail-start-stop-logging-arn

Conversation

@Mide69

@Mide69 Mide69 commented Jul 26, 2026

Copy link
Copy Markdown

CloudTrail: Fix start_logging/stop_logging to accept trail ARN

Closes #10107

start_logging/stop_logging did a raw self.trails[name] dict lookup, which raises KeyError when called with a trail ARN; AWS accepts both name and ARN for these operations, and get_trail_status already handles this correctly. Routes both methods through the existing ARN-tolerant get_trail() helper instead, matching the pattern already used by update_trail, put_event_selectors, etc. Unknown trails now correctly raise TrailNotFoundException.

Added tests covering start/stop by ARN and the not-found case for both methods. The full test_cloudtrail suite (45 tests) passes, and the ruff check/ruff format --check/mypy all clean.

start_logging and stop_logging did a raw self.trails[name] lookup,
raising KeyError when called with a trail ARN instead of a name.
Route through the existing get_trail() helper (already used by
update_trail and others) so both name and ARN resolve correctly,
and unknown trails raise TrailNotFoundException as AWS does.
@ApogeeAC

Copy link
Copy Markdown
Contributor

Duplicates #10119

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.

CloudTrail start_logging/stop_logging raise KeyError when called with a trail ARN

2 participants