Incorrect data in RHAISTRAT-1245 feature detail page

[nathan-weinberg]

What happened?

There are various fields in this page that seem to not be pulling the correct data from Jira

The fields I've noticed are:

1. Status color missing (status is Green on Jira)
2. Completeness widget shows 0% for all tracked values (feature is in fact Release Pending with all work complete)
3. No epics found - there is an Engineering epic under this - also likely the root cause of no Story Point/Issue data in the above point

Expected behavior

Data to align with field values in Jira

Steps to reproduce

https://team-tracker.apps.int.spoke.prod.us-west-2.aws.paas.redhat.com/#/releases/feature-detail?key=RHAISTRAT-1245&fromFeatureReview=1

Affected area

Dashboard / metrics

Diagnostics

[claude]

Claude finished @nathan-weinberg's task in 12m 52s —— View job • claude/issue-869-20260605-1301 • Create PR ➔

---

Investigating Feature Detail Page Data Issues

• Gather context and understand the codebase
• Investigate status color logic
• Investigate epic fetching logic
• Investigate completeness widget
• Determine fix approach
• Implement fix for status color derivation
• Run tests and lint (3752 tests pass, lint clean)
• Push changes and create PR

Root Cause Analysis

The feature detail page data comes from pre-computed JSON files generated by an external GitLab CI pipeline (feature-traffic). Three issues were identified:

1. Status color missing — The frontend expects an ownerStatusColor field, but the pipeline data and demo fixtures don't consistently populate it. However, features DO carry confidence-green/confidence-yellow/confidence-red labels that encode the same information. Fixed: Added server-side deriveOwnerStatusColor() that falls back to colorStatus field, then confidence-* labels. Also added case normalization in FeatureDetailView to match OverviewView behavior.

2. No epics found — The epics array is empty in the stored feature JSON for RHAISTRAT-1245, even though Jira shows an Engineering epic. This data is generated entirely by the external feature-traffic pipeline (redhat/rhel-ai/agentic-ci/feature-traffic). Cannot fix in this repo — requires investigation of the external pipeline's epic discovery logic. A manual refresh via Settings → Execution → Refresh may help if the data is simply stale.

3. Completeness shows 0% — This is a direct consequence of issue #2. The metrics object (totalEpics, totalIssues, completionPct, storyPoints) is computed from the epic/issue tree. With no epics, all metrics are zero. Resolves when issue #2 is fixed.

Changes Made

File	Change
modules/releases/server/execution/routes.js	Added deriveOwnerStatusColor() helper; enriches both feature list and detail endpoints
modules/releases/client/views/FeatureDetailView.vue	Normalized ownerStatusColor to uppercase (GREEN/YELLOW/RED) for case-insensitive matching
modules/releases/__tests__/server/execution/routes.test.js	Added 7 tests for derivation logic (labels, colorStatus fallback, preservation of existing values, index enrichment)

Note: Issues #2 and #3 (missing epics/metrics) require investigation of the external feature-traffic GitLab CI pipeline. As a first step, try triggering a manual data refresh from the Settings page to see if the epic data has been updated in the pipeline since the last fetch.

[nathan-weinberg]

A manual refresh via Settings → Execution → Refresh may help if the data is simply stale.

I was unable to find this in the Org Pulse dashboard

[accorvin]

@nathan-weinberg FYI I'm investigating this. That settings interface is only available to admins.

[nathan-weinberg]

Thank you Alex!

[accorvin]

Proposed Plan: Unified Feature Data Layer

After diagnosing the root cause of this issue, I've drafted a plan to fix the underlying architecture. The core problem is that feature detail data comes entirely from the external feature-traffic pipeline — when it produces stale/incomplete data, the app has no way to correct it.

Full plan: FEATURE-DATA-UNIFICATION-PLAN.md (on the current branch — will be moved to a feature branch for implementation)

TL;DR

Create a unified feature store where per-feature JSON files are enriched from both the pipeline AND live Jira data. Jira becomes the source of truth for fields it owns (status, colorStatus, assignee, epics, labels, etc.), while the pipeline keeps ownership of computed data (metrics, topology, completion %).

How it fixes the three reported issues

1. "Status color missing" → colorStatus fetched directly from Jira (customfield_10712). No longer depends on the pipeline populating ownerStatusColor.
2. "Status shows In Progress instead of Release Pending" → status and statusCategory fetched from Jira on every sync (default: every 6h).
3. "No epics found" → Epic discovery via JQL ("Epic Link" in (...) OR parent in (...)) — the same proven pattern used by the hygiene and delivery modules. Independent of pipeline's epic extraction.

Architecture

                    +---------------------------+
                    |   Unified Feature Store    |
                    |   features/{KEY}.json      |
                    +---------------------------+
                       ^       ^        ^
                       |       |        |
              Pipeline     Jira       Tracking
              ingest     enrichment    data
                       |       |        |
                       v       v        v
                    +---------------------------+
                    |    Derived Index           |
                    |    index.json              |
                    +---------------------------+
                              |
                    GET /features (list)
                    GET /features/:key (detail)

Key design decisions

• Field ownership table — every field has a clear owner (Jira or Pipeline) with explicit merge semantics
• Post-ingest enrichment — after pipeline artifacts download, Jira enrichment runs automatically (fail-safe: Jira outage never blocks pipeline data)
• Periodic 6h Jira sync — via the new cadence-aware refresh registry (PR feat: per-handler refresh cadence with admin overrides #877). Shows up automatically in the RefreshSettings admin panel.
• Per-feature on-demand refresh — POST /features/:key/refresh with 60s cooldown
• Config-driven rollout — jiraEnrichment.enabled: false by default, enable per-environment
• No breaking API changes — GET /features and GET /features/:key keep the same response shape
• Backward-compat field alias — both colorStatus and ownerStatusColor written during migration

5 implementation phases

1. Jira enrichment module (jira-enrich.js)
2. Merge logic + post-ingest hook (feature-store.js + gitlab-fetch.js modification)
3. Periodic Jira sync (jira-sync.js + registerRefresh with cadence: '6h')
4. Feature discovery (Jira JQL + tracking data reconciliation)
5. Index derivation + API updates (per-feature refresh endpoint)

Files: 3 new, 9 modified

New: jira-enrich.js, feature-store.js, jira-sync.js (all in modules/releases/server/execution/)

Modified: gitlab-fetch.js, routes.js, scheduler.js, module.json, fixtures, FeatureDetailView.vue, OverviewView.vue, DATA-FORMATS.md

What this does NOT change

• Feature tracking system (feature-tracking-routes.js) stays independent — it's a live Jira query for release-scoped views
• Hygiene module stays independent — shared Jira data consolidation deferred to a future iteration
• The external feature-traffic pipeline is unchanged — the app just enriches its output

---

Looking for input on this approach before proceeding with implementation. The full plan has detailed sections on merge semantics, epic discovery, partial failure handling, edge cases (demo mode, feature deletion, stale pipeline data), and deployment considerations.

🤖 Generated with Claude Code

[nathan-weinberg]

Still seeing incorrect data: https://team-tracker.apps.int.spoke.prod.us-west-2.aws.paas.redhat.com/#/releases/feature-detail?key=RHAISTRAT-1245&fromFeatureReview=1

[accorvin]

@nathan-weinberg sorry that this got closed prematurely - claude got a bit overzealous. I'm still working through this.

[nathan-weinberg]

no problem at all!

[accorvin]

@nathan-weinberg I think problems 1 and 3 are resolved now. I'm still digging on how the data flow for number 2 works.

[accorvin]

Working on a fix for this.