Backlog/v11 alerts view

[AlexSanchez-bit]

main changes

• simplify echoes request
• debounced and deduplicate alerts request on frontend side

[github-actions]

🛑 AI review — Blocking issues

One or more high/critical issues can break things and must be fixed before merging. Details below.

✅ architecture (silas-1.7-pro) — clean

Summary: Routine go-sdk version bump plus backend/frontend query optimizations; no architectural deviations detected.

No findings.

🛑 bugs (silas-1.7-pro) — blocking — must fix before merge

Summary: Alert view changes can leak/overwrite active RxJS subscriptions and debounce responses instead of requests; Java ES helper has minor NPE guard gaps.

• high frontend/src/app/data-management/alert-management/alert-view/alert-view.component.ts:368 — finalize() calls flushPendingFilters() before clearing this.lastRequest. If flushPendingFilters synchronously calls getAlert, the newly assigned this.lastRequest is overwritten by the old finalize or by the outer null after unsubscribe, leaking the subscription and causing duplicate/uncancelable alert requests. Repro: cancel an in-flight getAlert while a pending filter flush starts a new getAlert.
• medium frontend/src/app/data-management/alert-management/alert-view/alert-view.component.ts:365 — debounceTime(300) is applied to the HTTP search Observable, not to getAlert invocation/filter changes. Rapid calls to getAlert still unsubscribe the previous request and start a new network request, so the intended debounce is ineffective and can increase request churn. Repro: call getAlert several times within 300ms; each call still issues a request unless the response has already completed.
• medium frontend/src/app/data-management/alert-management/alert-view/alert-view.component.ts:366 — Moving this.loading=false and this.refreshingAlert=false into finalize means a superseded in-flight request resets UI state when it is unsubscribed at the start of a new getAlert. If the caller set loading/refreshing true for the new request, the old request's finalize can clear it before the new response arrives, hiding spinner/refresh state. Repro: trigger a refresh that replaces an in-flight alert list request.
• low backend/src/main/java/com/park/utmstack/service/elasticsearch/ElasticsearchService.java:475 — topHits.hits() may be null in unexpected ES responses; the current check calls topHits.hits().hits() without a null guard, risking NullPointerException. Use topHits.hits() != null && topHits.hits().hits() != null before isEmpty/get.

✅ security (silas-1.7-pro) — clean

Summary: Routine threatwinds/go-sdk bump and batched Elasticsearch echo lookup/Angular debounce changes; no introduced vulnerabilities or customer-facing disclosures identified.

No findings.

[utmstackprapprover]

Changes requested — Go dependencies check failed (see above).

[utmstackprapprover]

Changes requested — AI review found blocking issues (high/critical, or engineer review required). See above.

[AlexSanchez-bit]

• parentId list will be limited by page size, which is limited to less than 100 ids (alerts per page).
• debounceTime will debounce subject (request) execution, not response, so user will have a 300ms window to apply filters or paginations before the request is made
• subscriptions are only canceled after returning (either success or error) or when a new search request is made, so there's no orphan subscriptions on the request flow

[utmstackprapprover]

Changes requested — AI review found blocking issues (high/critical, or engineer review required). See above.