Repository navigation
fix: use timezone-aware datetime in raw-SQL and endpoint queries - #1781
Alicepoltora wants to merge 2 commits into
Conversation
…e-aware datetime.now(timezone.utc)
datetime.utcnow() was deprecated in Python 3.12 and returns a naive
datetime (no timezone). _format_created_at() should emit ISO 8601
strings that carry timezone info (+00:00) so the upstream metrics API
can parse the offset consistently with the rest of Studio.
The change replaces:
datetime.utcnow().isoformat()
with:
datetime.now(timezone.utc).isoformat()
Regression tests verify the returned string contains a timezone offset.
Three places used naive datetime.datetime.now() where timezone-aware datetimes are required: 1. backend/database_handler/transactions_processor.py:1010 recover_stuck_transactions() compares cutoff_time against Transactions.created_at which is DateTime(True) (tz-aware). Comparing naive vs tz-aware datetimes raises TypeError in Python 3. 2. backend/node/base.py:808 deploy_contract() falls back to naive datetime.now() which fails the assert transaction_datetime.tzinfo is not None in _run_genvm(). 3. backend/protocol_rpc/endpoints.py:2663 get_db_pool_status() returns a timestamp string without timezone info, inconsistent with all other Studio timestamps. All three now use datetime.now(timezone.utc). Regression tests verify the fixes work correctly.
|
This PR targeted I retargeted it to |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
Three places used naive
datetime.datetime.now()where timezone-aware datetimes are required:backend/database_handler/transactions_processor.py:1010—recover_stuck_transactions()comparescutoff_timeagainstTransactions.created_atwhich isDateTime(True)(tz-aware). Comparing naive vs tz-aware datetimes raisesTypeErrorin Python 3.backend/node/base.py:808—deploy_contract()falls back to naivedatetime.now()which fails theassert transaction_datetime.tzinfo is not Nonein_run_genvm()whenever nosim_config.genvm_datetimeoverride is provided.backend/protocol_rpc/endpoints.py:2663—get_db_pool_status()returns a timestamp string without timezone info, inconsistent with all other Studio timestamps.Fix
All three now use
datetime.now(timezone.utc).Tests
Regression tests verify the fixes work correctly.
Summary by CodeRabbit