Skip to content

OU-1040: feat/absolute start dates #749

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
rioloc wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

OU-1040: feat/absolute start dates #749

rioloc wants to merge 6 commits into from

Conversation

@rioloc
Copy link
Member

@rioloc rioloc commented Jan 30, 2026 •
edited
Loading

Problem

Start dates in tooltips are relatives to the numer of selected days as time span.

For example, if today is 30 Jan 2026 and an incident started on 22 Jan 2026, the Start date will be displayed as:

  • 29 Jan 2026 if "Last 1 Day" is selected
  • 27 Jan 2026 if "Last 3 Days" is selected
  • 23 Jan 2026 if "Last 7 Days" is selected
  • 22 Jan 2026 if "Last 15 Days" is selected. (The only correct one)

Fix

The absolute start date of an incident/alert is always displayed, and it is not related to the number of selected days.

Solution

Absolute timestamps for cluster_health_components_map{}, for incidents, and ALERTS{} for alerts are retrieved by performing an instant query call to Prometheus in order to get the min_over_time(timestamp(cluster_health_components_map{})), which return the timestamp of the first datapoint for that metric. (Same for ALERTS).
The result is saved into redux store and then used to match related incident/alert in order to update the Start date displayed in the tooltip.

Before

main.webm

After

feat.absolute-start-dates.webm

rioloc added 4 commits January 29, 2026 16:37
@rioloc
feat: absolute incidents timestamps support
ecbeb3e 
- add incidentsTimestamp in redux store
- add two extra calls to retrieve min_over_time and last_over_time for
  incidents
- enrich incident with absolute datapoints timestamps
- update IncidentTooltip labels with absolute Start and End times
@rioloc
feat: retrieve absolute start timestamps for alerts
5324341
@rioloc
feat: round absolute start dates to 5 minutes boundaries
55a5bc3
@rioloc
test: added unit to check absolute start dates
a3bbc15
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jan 30, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 30, 2026 •
edited by openshift-ci bot
Loading

@rioloc: This pull request references OU-1040 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Problem

Start dates in tooltips are relatives to the numer of selected days as time span.

For example, if today is 30 Jan 2026 and an incident started on 22 Jan 2026, the Start date will be displayed as:

  • 29 Jan 2026 if "Last 1 Day" is selected
  • 27 Jan 2026 if "Last 3 Days" is selected
  • 23 Jan 2026 if "Last 7 Days" is selected
  • 22 Jan 2026 if "Last 15 Days" is selected. (The only correct one)

Fix

The absolute start date of an incident/alert is always displayed, and it is not related to the number of selected days.

Solution

Absolute timestamps for cluster_health_components_map{}, for incidents, and ALERTS{} for alerts are retrieved by performoring an instant query call to Prometheus in order to get the min_over_time(timestamp(cluster_health_components_map{})), which return the timestamp of the first datapoint for that metric. (Same for ALERTS).
The result is saved into redux store and then used to match related incident/alert in order to then update the Start date displayed in the tooltip.

Before

main.webm

After

feat.absolute-start-dates.webm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 30, 2026
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 30, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 30, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rioloc
Once this PR has been reviewed and has the lgtm label, please assign jan--f for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rioloc rioloc mentioned this pull request Jan 30, 2026
Closed
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 30, 2026 •
edited by openshift-ci bot
Loading

@rioloc: This pull request references OU-1040 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Problem

Start dates in tooltips are relatives to the numer of selected days as time span.

For example, if today is 30 Jan 2026 and an incident started on 22 Jan 2026, the Start date will be displayed as:

  • 29 Jan 2026 if "Last 1 Day" is selected
  • 27 Jan 2026 if "Last 3 Days" is selected
  • 23 Jan 2026 if "Last 7 Days" is selected
  • 22 Jan 2026 if "Last 15 Days" is selected. (The only correct one)

Fix

The absolute start date of an incident/alert is always displayed, and it is not related to the number of selected days.

Solution

Absolute timestamps for cluster_health_components_map{}, for incidents, and ALERTS{} for alerts are retrieved by performing an instant query call to Prometheus in order to get the min_over_time(timestamp(cluster_health_components_map{})), which return the timestamp of the first datapoint for that metric. (Same for ALERTS).
The result is saved into redux store and then used to match related incident/alert in order to then update the Start date displayed in the tooltip.

Before

main.webm

After

feat.absolute-start-dates.webm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 30, 2026 •
edited by openshift-ci bot
Loading

@rioloc: This pull request references OU-1040 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Problem

Start dates in tooltips are relatives to the numer of selected days as time span.

For example, if today is 30 Jan 2026 and an incident started on 22 Jan 2026, the Start date will be displayed as:

  • 29 Jan 2026 if "Last 1 Day" is selected
  • 27 Jan 2026 if "Last 3 Days" is selected
  • 23 Jan 2026 if "Last 7 Days" is selected
  • 22 Jan 2026 if "Last 15 Days" is selected. (The only correct one)

Fix

The absolute start date of an incident/alert is always displayed, and it is not related to the number of selected days.

Solution

Absolute timestamps for cluster_health_components_map{}, for incidents, and ALERTS{} for alerts are retrieved by performing an instant query call to Prometheus in order to get the min_over_time(timestamp(cluster_health_components_map{})), which return the timestamp of the first datapoint for that metric. (Same for ALERTS).
The result is saved into redux store and then used to match related incident/alert in order to update the Start date displayed in the tooltip.

Before

main.webm

After

feat.absolute-start-dates.webm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@DavidRajnoha
Copy link
Contributor

DavidRajnoha commented Jan 30, 2026

/test e2e-incidents

rioloc added 2 commits January 30, 2026 17:29
@rioloc
fix: resolve stale closure issues causing empty AlertsChart and Incid…
466e7f4 
…entsTable on page refresh

- Fix initial state type mismatch for incidentsTimestamps and alertsTimestamps
  (was [] instead of { minOverTime: [], lastOverTime: [] })
- Add defensive check in matchTimestampMetricForIncident for undefined timestamps
- Refactor incidents useEffect to fetch timestamps and incidents in parallel,
  then use fetched values directly instead of stale closure values
- Refactor alerts useEffect with same pattern and add guards for empty
  incidentForAlertProcessing and timeRanges
- Add timeRanges and rules to alerts useEffect dependency array
- Remove unused alertsTimestamps selector

Assisted-By: Claude Opus 4.5
@rioloc
feat: edge case when 5m aggregated timestamp is greater than current …
14440d2 
…datapoint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@rioloc @openshift-ci-robot @DavidRajnoha