Don’t suppress JSON (de)serialization failures.

[zluudg]

⚠️ Potential issue | 🟠 Major

Don’t suppress JSON (de)serialization failures.

These branches currently return nil error on marshal/unmarshal failures, so upstream treats corrupted/unwritable state as success.

🔧 Suggested fix

 		updatedData, err = json.Marshal(firstReport)
 		if err != nil {
 			nc.log.Warning("Couldn't serialize first report: %s", err)
-			return found, nil
+			return found, err
 		}
@@
 		err = json.Unmarshal(data, &reportHistory)
 		if err != nil {
 			nc.log.Warning("Couldn't read report history: %s", err)
-			return found, nil
+			return found, err
 		}
@@
 		updatedData, err = json.Marshal(reportHistory)
 		if err != nil {
 			nc.log.Warning("Couldn't serialize updated report: %s", err)
-			return found, nil
+			return found, err
 		}

Also applies to: 217-221, 229-233

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/nats/nats.go` around lines 204 - 208, The marshal/unmarshal error
branches in internal/nats/nats.go (e.g., where updatedData =
json.Marshal(firstReport) and the related unmarshal paths) currently log the
error but return nil, which hides failures; change each such branch to return
the actual error instead of nil (e.g., replace returns like "return found, nil"
with "return found, err" or the appropriate tuple using the existing return
types) and keep the log call; apply the same fix to the other occurrences you
noted (the blocks around lines 217-221 and 229-233) so JSON (de)serialization
failures are propagated to callers.

Originally posted by @coderabbitai[bot] in #11 (comment)