chore(modernize): use slices.Backward where applicable#20103
chore(modernize): use slices.Backward where applicable#20103rhybrillou wants to merge 2 commits intomasterfrom
Conversation
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- In the loops converted to
for i, v := range slices.Backward(...)(e.g., infilterProcessesandfilterViolations), verify that the loop index is still correct for any subsequent indexing into the original slice, sincerange slices.Backwardyields indices 0..n-1 of the reversed view rather than the original slice indices. - The change in
combineStringstofor index := range slices.Backward(indices)alters the loop order semantics (andindexnow refers to the reversed-view index, not the original slice index) and also introduces a missingslicesimport in this file; consider either keeping the original index-based reverse loop or explicitly mapping the reversed iteration index back to the original slice index.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In the loops converted to `for i, v := range slices.Backward(...)` (e.g., in `filterProcesses` and `filterViolations`), verify that the loop index is still correct for any subsequent indexing into the original slice, since `range slices.Backward` yields indices 0..n-1 of the reversed view rather than the original slice indices.
- The change in `combineStrings` to `for index := range slices.Backward(indices)` alters the loop order semantics (and `index` now refers to the reversed-view index, not the original slice index) and also introduces a missing `slices` import in this file; consider either keeping the original index-based reverse loop or explicitly mapping the reversed iteration index back to the original slice index.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis pull request refactors reverse-loop iterations across seven files in the Go codebase, replacing manual decrementing index loops with the standard library's Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
pkg/notifiers/prune.go (1)
60-66:⚠️ Potential issue | 🟠 MajorAssign the sanitized process before pruning.
Line 62 drops the new
ProcessIndicatorreturned bycleanProcessIndicator, so Line 66 still marshals and later returns the original process objects. This can keep fields that pruning is meant to strip from notifications.Proposed fix
- for _, p := range processes { - cleanProcessIndicator(p) + for i, p := range processes { + processes[i] = cleanProcessIndicator(p) } for i, p := range slices.Backward(processes) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pkg/notifiers/prune.go` around lines 60 - 66, The loop calling cleanProcessIndicator currently discards its return value, so later pruning still uses the original ProcessIndicator; modify the code to assign the sanitized result back into the slice before the backward-prune loop (e.g., replace each processes[i] = cleanProcessIndicator(processes[i]) or otherwise store the returned ProcessIndicator), then use slices.Backward(processes) and jsonutil.MarshalToCompactString on the sanitized entries so pruned/stripped fields are not preserved in notifications.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@pkg/notifiers/prune.go`:
- Around line 60-66: The loop calling cleanProcessIndicator currently discards
its return value, so later pruning still uses the original ProcessIndicator;
modify the code to assign the sanitized result back into the slice before the
backward-prune loop (e.g., replace each processes[i] =
cleanProcessIndicator(processes[i]) or otherwise store the returned
ProcessIndicator), then use slices.Backward(processes) and
jsonutil.MarshalToCompactString on the sanitized entries so pruned/stripped
fields are not preserved in notifications.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: d87ce37d-4568-4070-b03d-f546a30d5f6c
📒 Files selected for processing (7)
central/policy/service/service_impl.gocentral/resourcecollection/datastore/datastore_impl_postgres_test.gopkg/httputil/interceptor.gopkg/notifiers/prune.gopkg/stringutils/empty.gosensor/kubernetes/networkpolicies/apply_tx.gosensor/upgrader/upgradectx/context.go
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #20103 +/- ##
=======================================
Coverage 49.68% 49.69%
=======================================
Files 2766 2766
Lines 209299 209299
=======================================
+ Hits 103994 104002 +8
+ Misses 97613 97606 -7
+ Partials 7692 7691 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🚀 Build Images ReadyImages are ready for commit 5ebf6a5. To use with deploy scripts: export MAIN_IMAGE_TAG=4.11.x-698-g5ebf6a5bd0 |
Description
Prepare for stricter
modernizelinting.User-facing documentation
is updated ORupdate is not neededis created and is linked above ORis not neededTesting and quality
Automated testing
How I validated my change
CI run.