Jira Timeline shows parented Tasks and Sub-tasks as top-level rows (and duplicates them)

[Dillon Liang]

On a team-managed business project (Jira Work Management), the Timeline view is rendering  issues TWICE at the same time: once correctly nested under their real parent, and once again as a top-level row, as siblings of the project's Epics. The flat copies have no expand chevron.

Every one of those 22 issues has a correct, non-null parent. I've confirmed that three separate ways:

- the REST API returns the right parent for each
- the issue detail panel shows the right Parent field and breadcrumb (e.g. "PARENT-KEY / CHILD-KEY")
- the Timeline's OWN GraphQL payload reports a populated parent for each of them

That last one is what makes me think this is server-side. The JiraTimelineQuery response returns these issues inside the root-level result set (data.jira.jiraIssueSearchView.issues.edges — 28 entries, being the 6 genuine Epics plus these 22), while the very same payload has parentIssueField.parentIssue.issueId populated on each of the 22 nodes. Request variables include "hierarchyEnabled": true, so the root set shouldn't contain anything that has a parent. The 6 real Epics correctly report parentIssue = null.

WHAT I'VE RULED OUT

Data - parents are correct everywhere I look, including in the payload that's misplacing them.

View settings - the Timeline's "Show/hide" panel only offers Hide done work items, Assignee column, Status column, and Warnings. There's no sub-task / nesting / hierarchy / rollup toggle to have set wrong.

Filters - none active, Clear all is greyed out, no assignee filter.

Browser cache - the flat rows survive a hard reload, and they reflect field edits made seconds earlier, so they're coming from the server.

Console errors - none. Just legacy AJS deprecation warnings and an "IndexedDB timed out" notice.

Stale per-issue index — every one of these forces an issue update and none of them changed anything:
- a status transition
- summary edits via REST API
- start/due date writes via REST API
- a parent change via REST API
- a parent change through the Jira web UI

That last one is the interesting one. Reassigning the parent in the UI removed the row from the flat block immediately (optimistic client update), and then a page refresh put it straight back. So the client and the server disagree about the same issue.

THE ONE PATTERN I CAN FIND

Issues created in this project by an automated REST API pass about a week earlier nest correctly — same project, same issue types, same parents, same creation mechanism, some of them with no dates at all.

Issues created or reparented by a REST API pass on one specific later day are the 22 that misbehave.

Feels like a hierarchy denormalisation or index artefact that ingested the earlier batch but never ingested the later one, and that per-issue updates don't trigger a re-ingest for.

MY QUESTIONS

1. Has anyone hit this, and did it resolve on its own?
2. Is there any supported way to force a hierarchy/parent re-index for a project without recreating the issues?
3. Is there something about creating issues via the REST API (a rank field, a specific create-vs-update ordering) that can leave them out of whatever the Timeline root query reads?