Add messageSendStatusInfo and disappearingMessageInfo

[wjuniorgit]

Adds decode code for logs of iOS MessageSendStatusEntity and the new DisappearingMessageInfoEntity when they exist for a message entity bug report.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Reports now optionally include “Disappearing message info” and “Message send status info” sections when provided in submissions.
  • Each new section is displayed under a clear header with the data shown as a JSON code block.
  • Parsing supports these new fields and renders them only when non-empty, improving clarity into message lifecycle details.

Walkthrough

Adds parsing and rendering for two new submit payload fields: disappearing_message_info and message_send_status_info. buildReportBody captures these values from the payload map and, when non-empty, renders each as a JSON code block under its own header in the generated report. Control flow otherwise unchanged.

Changes

Cohort / File(s)	Summary
Submit payload parsing and report rendering submit.go	Extend buildReportBody: parse disappearing_message_info and message_send_status_info from payload switch; store in new locals; conditionally render two new JSON sections under dedicated headers when values are non-empty. No exported API changes.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor Client
  participant Handler as Submit Handler
  participant Builder as buildReportBody
  participant Renderer as Report Renderer

  Client->>Handler: Submit payload (map)
  Handler->>Builder: buildReportBody(payload)
  activate Builder
  Builder->>Builder: Parse existing fields
  Builder->>Builder: Parse disappearing_message_info?
  alt has disappearing_message_info
    note right of Builder: Store JSON string
  end
  Builder->>Builder: Parse message_send_status_info?
  alt has message_send_status_info
    note right of Builder: Store JSON string
  end
  Builder->>Renderer: Assemble report body
  activate Renderer
  Renderer->>Renderer: Render standard sections
  alt non-empty disappearing_message_info
    Renderer->>Renderer: Render "Disappearing message info" JSON block
  end
  alt non-empty message_send_status_info
    Renderer->>Renderer: Render "Message send status info" JSON block
  end
  Renderer-->>Builder: Report body
  deactivate Renderer
  Builder-->>Handler: Report body
  deactivate Builder
  Handler-->>Client: Response with report

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title succinctly identifies the addition of messageSendStatusInfo and disappearingMessageInfo, directly reflecting the main change of adding those fields to the decoding and reporting logic and making the purpose of the pull request clear.
Description Check	✅ Passed	The description clearly explains that decode logic is being added for the iOS MessageSendStatusEntity and DisappearingMessageInfoEntity in message bug reports, which directly corresponds to the changes implemented in the pull request.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch wellington/ios-add-more-message-entity-info

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 5f6a389 and 7a05652.

📒 Files selected for processing (1)

• submit.go (3 hunks)

🔇 Additional comments (3)

submit.go (3)

972-973: LGTM! Variable declarations follow existing patterns.

The new local variables for messageSendStatusInfo and disappearingMessageInfo are declared consistently with other similar fields in the function.

---

987-990: LGTM! Extraction logic is correct.

The switch cases properly extract the new fields from the payload data map, following the same pattern as other specialized fields like decrypted_event_source and reply_path_pattern.

---

1016-1021: LGTM! Rendering logic follows established patterns.

The conditional rendering of the new fields as JSON code blocks is implemented correctly and consistently with how eventSource and other similar fields are handled. The non-empty checks ensure clean report output when these fields are not present.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}