fix(netfault): report repeated tc batch errors only once

[achoimet]

Context

Businessmap ticket 12109: running a network delay attack on a custom Ubuntu image showed the same error message many times in the action's error details.

tc -force -batch reports one error per failed batch line. Since a delay attack installs many filter rules, the rendered error repeated Error: Parent Qdisc doesn't exists. / We have an error talking to the kernel once per rule.

Change

Deduplicate identical messages when rendering batchErrors: the first occurrence is kept and repeats collapse into an (and N more) suffix on its Command failed -:<line> line.

The parsed error list itself is unchanged — filterBatchErrors ignore handling and the kernel-config hints behave exactly as before.

Example output after this change:

Command failed tc -force -batch -
Error: NLM_F_REPLACE needed to override.
Command failed -:1
Error: Failed to find specified qdisc.
Command failed -:2
Error: Parent Qdisc doesn't exists.
We have an error talking to the kernel
Command failed -:3 (and 11 more)

Extensions (extension-container, extension-host) pick this up via a regular action_kit_commons dependency bump — no changes needed there.

[claude]

Claude finished @achoimet's task in 2m 16s —— View job

---

Claude's Review

• Check for previously unresolved review threads from Claude (none found)
• Gather context (read changed files, diff)
• Understand the request (code review)
• Review code quality, bugs, security, performance, concurrency
• Post final review

Summary

Reviewed go/action_kit_commons/network/netfault/batch_error.go and its test file. The change deduplicates identical batchError messages purely in the (*batchErrors).Error() rendering path — the parsed Errors slice itself (and downstream filterBatchErrors/kernel-hint logic) is untouched, which matches the PR description and is confirmed by the added test (len(err.(*batchErrors).Errors) stays at 6 while the rendered string collapses repeats).

Went through the logic in detail:

• Dedup key is err.Msg (the accumulated message text before the Command failed line), with occurrences counted first and a reported set used to keep only the first occurrence per message, in original slice order — matches the example output in the PR body and the new test case.
• The (and N more) suffix is appended to the retained Command failed -:<line> line, using count-1, which is always ≥ 1 when appended since the branch only triggers for count > 1. No off-by-one or negative count risk.
• Error() only reads t.Errors/t.Cmd and allocates fresh local maps per call, so there's no shared mutable state and no concurrency concern here.
• No other call site in netfault.go parses the rendered error string (only filterBatchErrors operates on the structured Errors slice), so collapsing duplicate lines in the human-readable message doesn't break any downstream logic.

One minor edge case worth being aware of (not a bug introduced by this PR, and not blocking): if parseBatchError ever produces a batchError with an empty Msg (e.g., two consecutive Command failed lines with no message text between them), those would now be deduplicated together even though they represent distinct failed lines, and the line reference shown would be the first one. This is a pretty unlikely input shape for real tc -batch output, so it's just a note rather than something to fix.

Overall this is a small, well-tested, low-risk change. No bugs, security, or performance issues found.
(branch)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud