RHINENG-29406: compress remediations messages

[katarinazaprazna]

Summary

• Enable GZIP for remediations updates and raise the producer’s uncompressed message cap to 24 MiB
• Log and skip updates rejected as too large

Secure Coding Practices Checklist GitHub Link

• https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

• Input Validation
• Output Encoding
• Authentication and Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling and Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management
• General Coding Practices

Summary by Sourcery

Compress remediation updates and gracefully handle messages that exceed Kafka size limits.

New Features:

• Enable GZIP compression for remediation update messages with a 24 MiB uncompressed producer limit.

Bug Fixes:

• Handle oversized remediation updates by logging and skipping them instead of treating them as fatal publish errors.

[sourcery-ai]

Reviewer's Guide

Remediation updates now use a dedicated Kafka writer configured for GZIP compression and 24 MiB uncompressed batches, while updates that still exceed Kafka’s size limit are logged and skipped instead of failing publication.

File-Level Changes

Change	Details	Files
Add a dedicated GZIP-enabled Kafka writer with a larger uncompressed batch limit for remediation updates.	Refactor common Kafka writer construction into a reusable helper. Configure remediation publishing with GZIP compression and a 24 MiB batch limit. Preserve the existing writer retry, security, balancing, and environment-based configuration.	base/mqueue/mqueue_impl_gokafka.go evaluator/remediations.go
Gracefully handle remediation messages rejected because they exceed Kafka’s size limit.	Detect direct message-size errors and single-entry Kafka write errors. Log identifying metadata, issue count, payload size, and the rejection error. Skip oversized updates without treating them as fatal publish failures; propagate other Kafka errors normally.	evaluator/remediations.go

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 38.09524% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 58.89%. Comparing base (d875fde) to head (3cf9b48).

Files with missing lines	Patch %	Lines
evaluator/remediations.go	33.33%	6 Missing and 2 partials ⚠️
base/mqueue/mqueue_impl_gokafka.go	44.44%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2359      +/-   ##
==========================================
- Coverage   58.95%   58.89%   -0.07%     
==========================================
  Files         151      151              
  Lines        9690     9706      +16     
==========================================
+ Hits         5713     5716       +3     
- Misses       3375     3386      +11     
- Partials      602      604       +2     

Flag	Coverage Δ
unittests	58.89% <38.09%> (-0.07%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sourcery-ai]

Hey - I've found 3 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="evaluator/remediations.go" line_range="106" />
<code_context>
+	if isRemediationsMessageTooLarge(err) {
+		utils.LogError("inventoryID", state.HostID, "issue_count", len(state.Issues),
+			"uncompressed_bytes", len(msg.Value), "err", err, "Remediations update skipped: message too large")
+		return nil
+	}
 	return base.WrapFatalKafkaError(err, "write message")
</code_context>
<issue_to_address>
**Remediation snapshots remain stale**

When kafka rejects a remediation snapshot as too large, `publishRemediationsState` returns nil after logging the rejected write, so `Evaluate` and `evaluateHandler` treat the evaluation as successful and commit the input event. Consumers receive no replacement snapshot and retain missing or stale remediation state.

Return a non-nil error, or otherwise prevent the input event from being committed, when the snapshot write is rejected.
</issue_to_address>

### Comment 2
<location path="evaluator/remediations.go" line_range="120" />
<code_context>
+		}
+		err = writeErrors[0]
+	}
+	return errors.Is(err, kafka.MessageSizeTooLarge)
+}
</code_context>
<issue_to_address>
**Broker-rejected updates remain fatal**

When the broker rejects a compressed record batch for exceeding its configured size limit, `isRemediationsMessageTooLarge` matches only `kafka.MessageSizeTooLarge`; kafka-go reports a broker `MESSAGE_TOO_LARGE` response as `kafka.MessageTooLarge`, so `publishRemediationsState` wraps that rejection as fatal instead of logging and skipping it.

Recognize kafka-go’s broker-side `kafka.MessageTooLarge` error as well as the local `kafka.MessageSizeTooLarge` sentinel.
</issue_to_address>

### Comment 3
<location path="evaluator/remediations.go" line_range="111-120" />
<code_context>
 	return base.WrapFatalKafkaError(err, "write message")
 }
+
+func isRemediationsMessageTooLarge(err error) bool {
+	// Broker errors are wrapped in WriteErrors, which errors.Is does not unwrap
+	var writeErrors kafka.WriteErrors
+	if errors.As(err, &writeErrors) {
+		if len(writeErrors) != 1 {
+			return false
+		}
+		err = writeErrors[0]
+	}
+	return errors.Is(err, kafka.MessageSizeTooLarge)
+}
</code_context>
<issue_to_address>
**Size handling depends on Kafka error types**

When the remediation writer reports a too-large rejection without exposing a kafka-go `MessageSizeTooLarge` error, `isRemediationsMessageTooLarge` recognizes only kafka-go error wrappers, although `mqueue.Writer` exposes a generic `error` contract. A writer that reports an oversized message in another error shape bypasses the skip path and causes `publishRemediationsState` to return a fatal Kafka error.

Have the mqueue layer classify oversized-message failures behind a backend-independent error contract, and handle that contract in the evaluator.
</issue_to_address>

Sourcery assessment

Needs a human reviewer. 2 findings to address first, and an oversized remediation update is logged and treated as successful without being published, which can leave downstream remediation state stale. Reverting restores the previous writer behavior but cannot recover updates already skipped.

Blocking findings: evaluator/remediations.go:106, evaluator/remediations.go:120

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook