[Hardik K (hardikkaurani)]

Motivation & Context

In agent-framework (Python workflows), WorkflowCheckpoint.timestamp is an ISO 8601 timestamp string. While default timestamps generated by WorkflowCheckpoint include timezone information (UTC), timestamps supplied externally or written by tools can be offset-naive (e.g. "2026-01-01T00:00:00").

When storage.get_latest evaluates candidate checkpoints, _select_latest_checkpoint previously invoked datetime.fromisoformat(cp.timestamp) directly inside max(...). In Python, comparing an offset-naive datetime with an offset-aware datetime raises:

TypeError: can't compare offset-naive and offset-aware datetimes

This caused get_latest to fail unexpectedly whenever a storage held a combination of naive and timezone-aware timestamps.

Description & Review Guide

• What are the major changes?

  1. Added _parse_checkpoint_timestamp helper in _workflows/_checkpoint.py which normalizes naive timestamps by assigning timezone.utc.
  2. Updated _select_latest_checkpoint to use _parse_checkpoint_timestamp for max(...) timestamp calculation and candidate filtering.
  3. Added parameterized regression tests across InMemoryCheckpointStorage and FileCheckpointStorage in packages/core/tests/workflow/test_checkpoint.py verifying that get_latest selects the newest checkpoint without raising TypeError.

• What is the impact of these changes?

  • Prevents runtime TypeError when selecting latest checkpoints across mixed timestamp formats.
  • Consistent ordering semantics treating naive timestamps as UTC.
  • Zero breaking changes.

Related Issue

Fixes #9941

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change.

cc Eduard van Valkenburg (@eavanvalkenburg)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Eduard van Valkenburg (eavanvalkenburg)]

/review

[github-actions]

MAF Automated Review — Iteration 1

Result: No findings
Scope: full PR (2 commit(s)): 8cbe2a6de527, f935ace732cb
Model: gpt-5.6-sol

Overview

The PR narrowly normalizes offset-naive checkpoint timestamps to UTC before comparison while preserving aware-offset ordering and the existing lineage/ID tie-breakers. The regression test covers both core storage implementations and verifies both aware-newer and naive-newer selection. No publishable defect was established in the changed core path.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Eduard van Valkenburg (eavanvalkenburg)]

/review

[Hardik K (hardikkaurani)]

Hi Eduard van Valkenburg (@eavanvalkenburg),

The merge queue run 41804121496 failed due to a pytest-xdist worker crash (node down: Not properly terminated / runner memory pressure) in Python Integration Tests - Foundry during test_agui_provider_matrix.py, which was unrelated to this PR's core workflow checkpoint changes.

I've rebased the branch onto the latest main, verified that all checkpoint unit tests (85 passed) and ruff checks pass cleanly, and updated the branch.

Could you please re-add this PR to the merge queue when you have a moment? Thank you!