Repository navigation
feat(kubernetes): retain investigation history and recover long-running sync - #394
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Keeps Kubernetes investigations useful during long-running operation and preserves
new issue and Timeline evidence for later analysis, without redesigning the explorer.
recovery, deletion and recurrence alongside changes and crashes. Collection runs
without an open browser or notification channel. Historical totals remain
separate from current active-issue counts.
30 days, 90 days or all retained evidence. Filters and pagination stay available;
missing coverage is not reported as proof that nothing happened.
application age, record-count or total-byte retention cap. File storage uses
explicit 24-hour, 5,000-record and 4-MiB aggregate history budgets, protecting
active issue state rather than silently discarding it. Memory storage remains
ephemeral. These policies concern new captures, not an import of older history.
renewal, temporary provider/upstream failures and worker interruptions without
depending on a page visit or process restart. Refresh supported AWS signing
sessions and EKS bearer tokens as separate lifetimes, with bounded retries.
during ordinary refresh failures. Do not replace it with warming zeros, falsely
resolve issues or label query time as snapshot time. Routine refreshes keep the
existing top-bar indicator; Preparing does not return after first publication.
whole-scope denial, keep the failure visible and recover automatically after
reauthorization. Isolated unreadable resource types do not unnecessarily block
other authorized data. Partial recovery remains labelled Degraded where appropriate.
Raw container-log capture retains its existing separate limits. Static expired AWS
sessions and directly supplied bearer tokens cannot renew themselves; renewable
providers or externally replaced credentials are still required.
Why?
A long-running collector should not get trapped in a credential/retry loop, erase
useful views during refresh, or lose investigation evidence when Pods disappear.
Operators also need a clear distinction between incomplete evidence, denied access
and an actual healthy empty result.
Type of change
The resource-detail page is split into focused components with its existing public
behavior preserved. Persistent history starts with new captures; older history is
not imported. PostgreSQL capacity and intentional deletion remain operator-managed.
Checklist
go test ./...passes locally on the final release/CI snapshotgo vet ./...is clean in recorded affected-package validationsrc/for changed behaviorROADMAP.mdif this closes a roadmap item