[ccf-lisa]

Stacked on #357 (poc/menu-reorg). Depends on compliance-framework/api#513.

Why

Heavy Compliance Map users click a lot, and every click used to rebuild the whole lineage graph on the API: 320–400 ms per expand or drill-down. api#513 shares built engines across requests behind a TTL, so warm clicks take about 1 ms. Cached data can now be a few minutes old, so the UI has to say how old it is and let people rebuild it.

What changed

• useLineage (src/composables/useLineage/index.ts)
  • generatedAt: the oldest X-Lineage-Generated-At seen since the client cache was last cleared, so the label never claims fresher data than some node on screen. Missing or malformed headers are ignored.
  • refresh(): clears the client cache and sends refresh=true on the next roots fetch. Later requests reuse that rebuild.
  • takeUnscopedRefresh(): the drawer's per-SSP table always reads the unscoped engine. After a refresh in an SSP- or component-scoped view, the drawer's next /ssps request sends refresh=true so that engine is rebuilt too. An unscoped refresh already rebuilt it, so the flag is cleared.
• LineageScopeBar gets a Refresh button and an "Updated X ago" label (useTimeAgo; the full time is in the tooltip).
• Tree and graph views pass generatedAt and the busy state, and handle refresh. The tree keeps its expanded nodes and selection, and the graph replays its drill-down path. The button stays disabled until the whole reload is done, roots plus replay, so a second click can't start an overlapping replay.

Without api#513 it degrades gracefully: no header means no label, and the API ignores the unknown refresh param, so Refresh just refetches.

Testing

• make reviewable (formatcheck, typecheck, lint, unit tests): 1,832 tests pass.
• New and extended specs:
  • useLineage.spec: refresh param on the next roots fetch only, oldest generated-at, bad headers, scoped vs unscoped follow-up.
  • LineageScopeBar.spec: emit, disabled state, label.
  • LineageTreeView.spec: refresh keeps the expanded nodes.
  • LineageGraphView.spec: refresh replays the path and stays busy until the replay is done.
  • LineageNodeDrawer.spec: a refreshed node object reloads the drawer's panels.

Open questions for reviewers

None.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 3965a6be-2048-42f1-8a40-91e49360d8e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gusfcarvalho]

ccf-review: REQUEST_CHANGES

3 Must-fix, 1 Nit.

Stack (gh stack 359): #357 → #358

Outside the diff

• [Must-fix] src/composables/useLineage/index.ts:186 A request in flight when Refresh is clicked writes pre-refresh data back into the cleared cache: refresh() clears the module cache, but a getChildren (or getRoots) call already awaiting the API still runs cache.set(ck, nodes) and noteGeneratedAt(...) when it resolves. Because Refresh doesn't change the scope, the cache key is the same, so the stale result lands in the fresh cache. Reachable: expand a large node, then click Refresh before its children arrive. The node-expand fetch doesn't disable the button. The old response then fills the cache under the same key. When the view replays its expanded nodes after the refresh, it gets those pre-refresh children from the cache, and the label moves back to the old time. Before this PR the only cache reset was a scope change, and the key includes the scope, so a late response could never land in the new cache. (2af4f09a72f0)

[ccf-lisa]

Review body item (Outside the diff, Must-fix, src/composables/useLineage/index.ts): fixed in 3676dd6. clearCache() now bumps a module-level generation counter; getRoots/getChildren capture it before the API request and, if it changed by the time the response (or the fixture fallback after a failure) arrives, return the nodes without cache.set, noteGeneratedAt or touching the pending refresh flags. New spec in useLineage.spec: a deferred fetchChildren, then refresh(), then the old fetch resolves; generatedAt stays null and a new fetchChildren for that key calls the API again (fails without the fix).

[gusfcarvalho]

ccf-review: APPROVE

no findings.

Stack (gh stack 359): #357 → #358

[ccf-lisa]

PR approved. Marking ready for e2e.