Skip to content

fix: match invalid checkpoint token casing - #723

Open
vyrnsynx wants to merge 2 commits into
aws:mainfrom
vyrnsynx:fix/invalid-checkpoint-token-case
Open

vyrnsynx wants to merge 2 commits into
aws:mainfrom
vyrnsynx:fix/invalid-checkpoint-token-case

Conversation

@vyrnsynx

Copy link
Copy Markdown

Issue #, if available:: #721

Description of changes:

The service emits Invalid checkpoint token (lowercase). The SDK matched a Title Case prefix, so a stale checkpoint token was classified as a non-retryable execution failure instead of a retryable invocation failure.

  • Compare the message prefix case-insensitively
  • Cover both the service casing and the previous Title Case string in unit tests

Testing:

  • hatch run dev-core:test: 1670 passed
  • hatch fmt --check in the core package: passed

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Service emits "Invalid checkpoint token" (lowercase). The SDK
compared with a Title Case prefix, so stale tokens were treated
as non-retryable execution failures.

Compare case-insensitively and cover both casings in unit tests.

Fixes aws#721
@hln33

hln33 commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

Thank you for the contribution!

Overall approach looks good to me - just some small requested changes.

Also, I ran the CI tests for this PR and it looks like some checks are failing. Can you please have a look and address that as well? Example failure.

@hln33 hln33 added the changes-requested Reviewer requested changes; waiting on the author label Sep 14, 2026
],
)
def test_checkpoint_error_classification_invalid_token_invocation(message: str):
"""Service emits lowercase 'checkpoint token'; match case-insensitively as invocation."""

@hln33 hln33 Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer the original description for this test.

I feel that it more clearly conveys what the purpose of the test is. The original also follows the format that most of the test descriptions in this file use.

Maybe something like this is better:

Suggested change
"""Service emits lowercase 'checkpoint token'; match case-insensitively as invocation."""
"""Test 4xx InvalidParameterValueException with "Invalid checkpoint token" error message is an invocation error."""

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Restored the original-style test description and dropped the parametrize so we only cover the backend casing.

INVALID_CHECKPOINT_TOKEN_PREFIX
)
and (error.get("Message") or "")
.casefold()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's perform an exact string match instead of doing a lowercase/casefold match. The main purpose is to match the backend exactly. If the error message does not exactly match we wouldn't want this condition to be true.

Can you please make this comparison case-sensitive and amend the other changes in this PR to reflect that?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to an exact case-sensitive .startswith("Invalid checkpoint token") match (no casefold) so we only treat the backend’s exact message as invocation.

Match the backend error prefix case-sensitively and restore the
single-unit test description preferred in review.
@vyrnsynx

Copy link
Copy Markdown
Author

Updated per review: switched to an exact case-sensitive match on Invalid checkpoint token, and restored the original-style test description for the single backend-casing case.

@hln33

hln33 commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

LGTM!

Integration/Conformance tests are failing due to missing credentials, but that is expected for external PRs as we only grant secrets to internal contributors. All other CI checks are passing.

Thanks once again for your contribution!

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

Labels

changes-requested Reviewer requested changes; waiting on the author

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants