[Java-SDK] Externe AttachmentId wird beim Senden überschrieben [OpenCode #91]

Bug Classification

• Affects multiple customers
• Affects only one customer

Customer Interaction

• Yes, reviewed together with the customer via TeamViewer
• Yes, documented via screenshots
• No, meeting is still pending
• No interaction yet

Description of the Bug

Bei Verwendung des Java-SDK wird eine vom Aufrufer gesetzte AttachmentId beim Erstellen des Payloads überschrieben. Dadurch geht die fachliche Referenz zwischen Fachdaten und Attachment verloren. Im .NET-SDK wurde dieses Verhalten bereits behoben (Fix in v3.0.3, Commit f71a11c6 vom 12.01.2026).

1. Attachment mit eigener attachmentId im Java-SDK erzeugen (z. B. über new Attachment(UUID, ...)).
2. Submission/Reply mit diesem Attachment über Java-SDK versenden.
3. In der ausgehenden Verarbeitung/Metadata bzw. Announcement prüfen, welche ID verwendet wird.
4. Beobachtung: Java-SDK ersetzt die ID durch neue zufällige UUID(s), Referenzen auf die fachlich gesetzte ID brechen.

Current behavior:

Java-SDK setzt in AttachmentPayloadHandler die attachmentId immer per UUID.randomUUID() neu, auch wenn am Attachment bereits eine ID gesetzt wurde.

Expected behavior:

Wenn eine attachmentId gesetzt ist, muss diese unverändert übernommen werden. Nur wenn keine ID gesetzt ist, darf das SDK eine UUID erzeugen.

Environments:

Additional Information:

• Betroffen im Java-SDK weiterhin reproduzierbar (u. a. bis Tag 3.1.3).
• Abweichung zwischen SDKs:
  • .NET-SDK: Fix vorhanden in v3.0.3
  • Java-SDK: weiterhin nicht konform zur REST-API und zum .NET-Verhalten

Dependency / relationship to other issues:

Responsible person / team:

Transfer history to different teams

Contact persons including contact details:

Screenshots / Logs / Requests:

Checklist:

• Add Severity label
• Add team label
• Related/affected issues/stories/epics linked and explained in the bug issue
• Creation of an automated test
• Bugfix deployed on DEV
• Bugfix tested on DEV
• Bugfix deployed on TEST
• Bugfix tested on TEST (possibly also by the connection project itself)
• Successful fix reported to Team Operations (Teams channel)
• Bugfix deployed on STAGE
• Bugfix tested on STAGE if necessary
• Bugfix deployed on PROD
• Bugfix tested on PROD (possibly also by the connection project itself)
• Final communication by Team Operations if necessary
• Internal documentation was checked and updated if necessary
• External documentation has been checked and updated if necessary
• Updated changelog if necessary

Approach/Solution:

• Java-SDK anpassen: in AttachmentPayloadHandler gesetzte Attachment.attachmentId übernehmen, statt immer UUID.randomUUID().
• Fallback nur bei null: neue UUID erzeugen.

Release version of the artifact: