feat: add extraFields to Result.Issue (OD-41)

[andrzej-janczak]

What

Adds extraFields: Option[String] = None to Result.Issue — the first link needed to propagate tool-specific structured metadata (e.g. Trivy dependency chains) from a tool's output all the way to srm-service.

Why String, not Json

This module is explicitly "a dependency free api" and cross-builds Scala Native, so it can't take a circe dependency. extraFields therefore holds the raw JSON string; the actual JSON (de)serialization of the embedded value is handled by the circe codecs in codacy-plugins (see OD-42).

Chain

codacy-trivy → codacy-plugins-api Result.Issue (this PR) → codacy-plugins PluginResult (OD-42) → codacy-worker (OD-20, PR #1206).

Verification

• codacy-plugins-apiJVM/compile ✓ (Scala 2.12). Backward compatible: new field defaults to None.

Follow-up

Once published, bump in codacy-plugins (OD-42).

Linear: OD-41

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 duplication

Metric	Results
Duplication	0

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[gemini-code-assist]

Code Review

This pull request introduces an optional extraFields field to the Result.Issue case class to support tool-specific structured metadata. However, adding a new field to a case class breaks binary compatibility in Scala, which could lead to runtime errors in downstream dependencies. It is recommended to add an overloaded apply method in a companion object to mitigate this issue and to perform a version bump for downstream recompilation.

[gemini-code-assist]

Adding a new field to a case class, even with a default value, breaks binary compatibility in Scala. The JVM signature of the constructor, apply, unapply, and copy methods will change. Any downstream dependency compiled against the previous version of this library will throw a NoSuchMethodError or LinkageError at runtime if they attempt to instantiate or pattern match on Result.Issue without being recompiled.

To mitigate this and maintain binary compatibility for direct instantiations (via apply), you can define an explicit companion object with an overloaded apply method that accepts 6 arguments. Note that pattern matching (unapply) and copy will still remain binary-incompatible, so a minor/major version bump and recompilation of downstream consumers is highly recommended.

  case class Issue(filename: Source.File,
                   message: Result.Message,
                   patternId: Pattern.Id,
                   line: Source.Line,
                   suggestion: Option[Suggestion],
                   sourceId: Option[String],
                   extraFields: Option[String] = None)
      extends Result

  object Issue {
    def apply(filename: Source.File,
              message: Result.Message,
              patternId: Pattern.Id,
              line: Source.Line,
              suggestion: Option[Suggestion],
              sourceId: Option[String]): Issue = {
      Issue(filename, message, patternId, line, suggestion, sourceId, None)
    }
  }

[codacy-production]

Pull Request Overview

While the implementation adds the extraFields field to Result.Issue as requested, it introduces a critical breaking change for the Scala ecosystem. Specifically, modifying the Issue case class disrupts binary compatibility for existing plugins and breaks source compatibility for any logic relying on pattern matching. Furthermore, the PR is entirely missing unit tests to validate the new field or guarantee that existing constructor calls remain functional. Although Codacy reports the PR as 'Up to Standards', this is due to the small footprint of the change rather than a verification of logical safety. These issues should be resolved, preferably by providing a compatibility layer and test suite, before the PR is merged.

About this PR

• No unit tests were included in this PR to verify the new field's behavior or ensure that existing code using the 'Issue' constructor still compiles and functions as expected.
• The PR description references 'Linear: OD-41' while the linked JIRA ticket is ODIN-20 (duplicate of OD-20). This should be corrected for clear traceability.

Test suggestions

• Verify that 'Result.Issue' can be instantiated without providing 'extraFields', defaulting to 'None'.
• Verify that 'Result.Issue' correctly stores and retrieves a raw JSON string provided in 'extraFields'.

Prompt proposal for missing tests

Consider implementing these tests if applicable:
1. Verify that 'Result.Issue' can be instantiated without providing 'extraFields', defaulting to 'None'.
2. Verify that 'Result.Issue' correctly stores and retrieves a raw JSON string provided in 'extraFields'.

_{TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback}

[codacy-production]

_{🔴 HIGH RISK}

Adding extraFields to the Issue case class is a binary and source-breaking change. It breaks binary compatibility for existing plugins and source compatibility for code using pattern matching on Issue. If binary stability is required, consider using a regular class with custom apply and unapply methods or ensure this change is part of a major version release. Try running the following prompt in your coding agent: > Provide a compatibility layer for the Issue case class to support existing 6-parameter calls and pattern matches after adding a 7th parameter.