Skip to content

Azure Monitor API rejecting timespan format#1003

Merged
pragya811 merged 2 commits into
mainfrom
jenkins_fix4
Jun 11, 2026
Merged

Azure Monitor API rejecting timespan format#1003
pragya811 merged 2 commits into
mainfrom
jenkins_fix4

Conversation

@pragya811

@pragya811 pragya811 commented Jun 10, 2026

Copy link
Copy Markdown
Member

Type of change

Note: Fill x in []

  • bug
  • enhancement
  • documentation
  • dependencies

Description

Problem: Azure Monitor API was rejecting timespan format due to non-ISO 8601 datetime formatting. Found from azure daily policies run Jenkins job.

For security reasons, all pull requests need to be approved first before running any automated CI

Assisted-by: Cursor

@coderabbitai

coderabbitai Bot commented Jun 10, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The PR updates Azure metrics timespan construction in get_resource_metrics to explicitly format start and end datetimes using ISO-8601 format (isoformat()) instead of relying on raw datetime object serialization when the caller does not provide an explicit timespan parameter.

Changes

Metrics Timespan Serialization

Layer / File(s) Summary
Timespan ISO-8601 formatting
cloud_governance/common/clouds/azure/monitor/monitor_management_operations.py
The get_resource_metrics method now constructs the timespan parameter for Azure metrics queries using explicit ISO-8601 format via start_date.isoformat() and end_date.isoformat() instead of relying on implicit datetime serialization.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: fixing the Azure Monitor API's rejection of timespan format by converting to ISO 8601 formatting.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description check ✅ Passed The PR description clearly explains the issue (Azure Monitor API rejecting timespan format), root cause (non-ISO 8601 datetime formatting), and how it was discovered (Jenkins job), directly corresponding to the code changes that fix datetime serialization to use ISO-8601 format.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch

Comment @coderabbitai help to get the list of available commands and usage tips.

@pragya811 pragya811 marked this pull request as draft June 10, 2026 12:08

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@cloud_governance/common/clouds/azure/monitor/monitor_management_operations.py`:
- Line 84: The timespan strings in
cloud_governance/policy/helpers/azure/azure_policy_operations.py are built using
f'{start_date}/{end_date}' where start_date/end_date are datetime objects from
Utils.get_start_and_end_datetime(); change these to use ISO 8601 formatting like
f'{start_date.isoformat()}/{end_date.isoformat()}' in every call site (the three
places around the reported locations) so they match
monitor_management_operations.py and meet Azure Monitor's
startDateTime_ISO/endDateTime_ISO requirement.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 85a13054-02b5-40cb-af63-ed76d868c163

📥 Commits

Reviewing files that changed from the base of the PR and between 4faca1f and 68ed993.

📒 Files selected for processing (1)
  • cloud_governance/common/clouds/azure/monitor/monitor_management_operations.py

@pragya811 pragya811 marked this pull request as ready for review June 10, 2026 12:14

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🧹 Nitpick comments (1)
cloud_governance/policy/helpers/azure/azure_policy_operations.py (1)

201-202: ⚡ Quick win

Consider extracting timespan construction into a helper method.

The identical timespan formatting pattern is repeated across three methods. Extracting it would improve maintainability and ensure consistency if the formatting logic needs adjustment.

♻️ Example refactor
def _build_timespan(self, days: int) -> str:
    """Build ISO-8601 formatted timespan string for Azure Monitor queries."""
    start_date, end_date = Utils.get_start_and_end_datetime(days=days)
    return f'{start_date.isoformat()}/{end_date.isoformat()}'

Then use in each method:

timespan = self._build_timespan(days=days)

Also applies to: 220-221, 240-241

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@cloud_governance/policy/helpers/azure/azure_policy_operations.py` around
lines 201 - 202, The repeated construction of the Azure Monitor timespan string
using Utils.get_start_and_end_datetime(days=days) and
f'{start_date.isoformat()}/{end_date.isoformat()}' appears in multiple methods;
extract this into a private helper method (e.g., _build_timespan(self, days:
int) -> str) that calls Utils.get_start_and_end_datetime and returns the
formatted ISO-8601 timespan, then replace the three inline occurrences (where
timespan is constructed around Utils.get_start_and_end_datetime) with calls to
self._build_timespan(days=days) to centralize formatting and ensure consistency.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@cloud_governance/policy/helpers/azure/azure_policy_operations.py`:
- Around line 201-202: The repeated construction of the Azure Monitor timespan
string using Utils.get_start_and_end_datetime(days=days) and
f'{start_date.isoformat()}/{end_date.isoformat()}' appears in multiple methods;
extract this into a private helper method (e.g., _build_timespan(self, days:
int) -> str) that calls Utils.get_start_and_end_datetime and returns the
formatted ISO-8601 timespan, then replace the three inline occurrences (where
timespan is constructed around Utils.get_start_and_end_datetime) with calls to
self._build_timespan(days=days) to centralize formatting and ensure consistency.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 91c6dfe6-090b-49de-bc4d-7ea14669e021

📥 Commits

Reviewing files that changed from the base of the PR and between 68ed993 and 04ed465.

📒 Files selected for processing (1)
  • cloud_governance/policy/helpers/azure/azure_policy_operations.py

@pragya811 pragya811 requested a review from ebattat June 10, 2026 12:18

@ebattat ebattat left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

/approve

@pragya811 pragya811 merged commit 2ddb7f7 into main Jun 11, 2026
24 checks passed
@github-project-automation github-project-automation Bot moved this from In progress to Done in Cloud-Governance project Jun 11, 2026
@pragya811 pragya811 deleted the jenkins_fix4 branch June 11, 2026 07:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

2 participants