Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-9427

Safeguard Against Stale Data and Increase API Timeout for Pipeline Overview

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • UI
    • None
    • Pipelines Sprint Pioneers 43
    • Customer Escalated, Customer Facing, Customer Reported

      Story

      As a user relying on the Pipeline Overview dashboard for up-to-date pipeline insights
      I want data to always reflect the latest server state and avoid load failures due to short timeouts
      So that the dashboard remains accurate, reliable, and responsive even under higher load or slower API conditions.


      Background

      Customers reported seeing stale or partially outdated data on the Pipeline Overview page during slow API responses or intermittent backend delays. The default 60s timeout has been insufficient in certain clusters, leading to silent load failures. We need to add safeguards that prevent stale data from being displayed and increase the API timeout where necessary.


      Out of Scope

      • Modifying backend caching behavior.
      • Introducing new APIs for freshness indicators.
      • Refactoring UI beyond data-loading workflow.

      Approach

      • Add checks preventing cached/previous response data from rendering when a new request is in-flight or when a request fails.
      • Ensure UI renders only the latest, complete successful response.
      • Update the API client configuration to allow a 90s timeout for dashboard summary calls (default remains 60s unless override is required).
      • Add logging/debug signals for timeout or stale-render scenarios.

      Dependencies

      • Tekton Results API availability
      • Console plugin data-fetch layer

      Acceptance Criteria

      • Stale data is never shown after a refresh or filter change.
      • If a request times out or fails, the dashboard does not render old data; it should fallback to error state.
      • Timeouts can be increased to 90s and verified through configuration.
      • UI must update only when the latest request completes.
      • Automated tests cover:
        • stale-data prevention logic
        • timeout handling
        • error fallback behavior

      INVEST Checklist

      • Dependencies identified
      • No open blockers
      • Design implementable
      • Acceptance criteria agreed
      • Story estimated

      Done Checklist

      • Code completed, reviewed, documented, and checked in
      • Unit and integration tests added and passing in CI
      • CI/CD pipeline works with the updated behavior
      • Customer-facing documentation updated
      • All acceptance criteria met

              rh-ee-apalit Anwesha Palit
              rh-ee-apalit Anwesha Palit
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: