Repository navigation
test: cover Stellar auto-remediation dispatch path - #24213
Conversation
…/queueAutoTendAction/autoCreateWatch) Adds unit coverage for the three previously-untested Stellar event auto-remediation branches: auto-executing a RestartDeployment action with no human approval, queueing a non-restart action for approval, and auto-creating/refreshing a watch for a recurring event. Also documents (via two tests whose names and inline comments make the current behavior explicit) that CreateStellarAction never persists idempotency_key, so the dedup short-circuit in both auto-remediation paths cannot currently prevent duplicate actions. Filed as a separate production-code bug since fixing store persistence is out of scope for test-only changes. Signed-off-by: quality <quality@hive.kubestellar.io>
✅ Deploy Preview for kubestellarconsole canceled.
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
👋 Hey @hivecommons-hive[bot] — thanks for opening this PR!
This is an automated message. |
There was a problem hiding this comment.
Read the tested code at this head, not just the diff. The test assertions match the tree:
autoExecuteAction(pkg/api/handlers/stellar/watches_eventprocessing.go:347-352) does delegate non-RestartDeploymenttypes toqueueAutoTendAction, which no-ops for them (watches_eventprocessing.go:489-492) — so the "silent no-op" comment in the test is accurate.- The #24212 claim is real:
CreateStellarAction's INSERT (pkg/store/sqlite_stellar_actions.go:64-66) omitsidempotency_key, soActionCompletedByIdempotencyKey(sqlite_stellar_actions.go:277) can never match a row created through it. The two*_IdempotencyKeyDedupIsCurrentlyBrokentests correctly pin current behavior and say what to flip when #24212 lands — the store's own test already works around this withsetActionColumnForTest(pkg/store/sqlite_stellar_actions_test.go:169), confirming the gap. autoCreateWatchcreate-vs-touch behavior matcheswatches_eventprocessing.go:615-626.
Test-only change in an existing package, so the coverage-ratchet completeness gate isn't implicated. Looks correct to me.
— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.88
|
Thank you for your contribution! Your PR has been merged. Check out what's new:
Stay connected: Slack #kubestellar-dev | Multi-Cluster Survey |
|
Post-merge build verification passed ✅ Both Go and frontend builds compiled successfully against merge commit |
✅ Post-Merge Verification: passedCommit: |
Test Improvement
Adds unit coverage for
pkg/api/handlers/stellar/watches_eventprocessing.go's auto-remediation dispatch path —autoExecuteAction,queueAutoTendAction, andautoCreateWatch— which previously had zero unit or e2e coverage (confirmed by grepping every*_test.gofile in the package for these symbol names).Covers:
autoExecuteAction: delegation toqueueAutoTendActionfor non-RestartDeploymenttypes.queueAutoTendAction: no-op for non-RestartDeploymenttypes; successful queue creates a pending action + notification.autoCreateWatch: creates a new watch vs. refreshes (not duplicates) an existing one.While writing these tests, discovered that
CreateStellarAction's INSERT never persistsidempotency_key, so the dedup short-circuit these functions rely on can never fire for genuinely created rows — filed separately as #24212 since it's a production persistence bug, out of scope for a test-only PR. Two tests here (*_IdempotencyKeyDedupIsCurrentlyBroken) intentionally assert the current (buggy) behavior with inline notes on what to flip once #24212 lands, so this PR doesn't block on that fix landing first.Verified locally:
go test ./pkg/api/handlers/stellar/...passes (23.7s, all tests green) andgo vetis clean.Closes #24211
Filed by quality agent (ACMM L4/L6 — full mode)
— hive: agent=quality backend=copilot model=claude-opus-4.7 copilot=1.0.88