comment format payload limit fixes

[Bala-Sakabattula]

Changed the code if the comment payload limit exceeds 32767 characters than truncating the comment payload and adding the link of github issue url at the end.

[qodo-code-review]

Review Summary by Qodo

Implement Jira comment body truncation with GitHub issue links

🐞 Bug fix ✨ Enhancement

Walkthroughs

Description

• Add Jira comment body truncation to enforce 32767 character limit
• Implement _truncate_jira_comment_body() function with warning notices
• Include upstream GitHub issue link in truncation notices when available
• Update comment matching and formatting to use truncation function
• Add comprehensive unit tests for truncation logic

Diagram

flowchart LR
  A["Comment formatting"] -->|exceeds 32767 chars| B["_truncate_jira_comment_body()"]
  B -->|prepend warning| C["Truncated comment"]
  B -->|append notice| C
  D["Upstream issue URL"] -->|optional link| C
  C -->|safe for Jira| E["Add to Jira"]

Loading

File Changes

1. sync2jira/downstream_issue.py ✨ Enhancement +61/-6

Add comment truncation with GitHub issue links

• Added JIRA_COMMENT_BODY_MAX_CHARS constant set to 32767
• Implemented _truncate_jira_comment_body() function to enforce character limit with warning
 notices
• Updated _find_comment_in_jira() to accept and use upstream_issue_url parameter
• Modified _comment_matching() to pass upstream_issue_url to comment matching logic
• Updated _update_comments() to pass issue URL to truncation and matching functions

sync2jira/downstream_issue.py

---

2. tests/test_downstream_issue.py 🧪 Tests +24/-1

Add tests for comment truncation logic

• Updated test_update_comments() to verify upstream_issue_url is passed to _comment_matching()
• Added test_truncate_jira_comment_body_short_unchanged() to verify short comments pass through
 unchanged
• Added test_truncate_jira_comment_body_long_with_issue_url() to test truncation with GitHub link
• Added test_truncate_jira_comment_body_long_without_url() to test truncation without GitHub link

tests/test_downstream_issue.py

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (0)   📎 Requirement gaps (0)   🖥 UI issues (0)   🎨 UX Issues (0)

🐞\ ≡ Correctness (1)

1. Truncation breaks quote markup 🐞 ≡

Description

_truncate_jira_comment_body() truncates by slicing the entire formatted comment string and appending
a tail, which can remove structural Jira wiki markup like the closing "{quote}" produced by
_comment_format(). This can cause the truncation warning/link to render inside an unclosed quote
block (or otherwise render incorrectly) for comments that exceed Jira’s size limit.

Code

sync2jira/downstream_issue.py[R298-299]

+    truncated_core = body[: max(budget, 0)]
+    return head + truncated_core + tail

Evidence

_comment_format() wraps the upstream body in an opening and closing "{quote}" marker, but the new
truncation helper slices the full formatted string (which includes those markers) without ensuring
the closing marker remains. The truncation helper is invoked on the output of _comment_format()
during both duplicate-detection/update and new comment creation, so any long comment will be stored
in Jira with potentially broken wiki markup.

sync2jira/downstream_issue.py[239-253]
sync2jira/downstream_issue.py[292-299]
sync2jira/downstream_issue.py[541-556]
sync2jira/downstream_issue.py[1121-1129]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Long Jira comments are truncated by slicing the *already-formatted* comment text returned by `_comment_format()`. That formatted text includes Jira wiki markup (`{quote}...{quote}`), and truncation can remove the closing `{quote}` (or cut through markup), causing the truncation warning/link tail to render incorrectly (often inside an unclosed quote block).

### Issue Context
- `_comment_format()` emits `{quote}` blocks around the upstream body.
- `_truncate_jira_comment_body()` currently truncates via `body[:budget]` and then appends a warning tail.
- This truncation is applied to `_comment_format(comment)` when adding/updating Jira comments.

### Fix Focus Areas
- sync2jira/downstream_issue.py[239-253]
- sync2jira/downstream_issue.py[256-300]
- sync2jira/downstream_issue.py[541-556]
- sync2jira/downstream_issue.py[1121-1129]

### Suggested fix approach
1. **Avoid truncating the fully formatted string.** Instead, truncate the *raw* upstream `comment["body"]` (or a clearly delimited “core” portion) and then build the final Jira comment so structural markup is always closed.
  - Compute the overhead length for the non-body parts: header (id/author/date + opening `{quote}`), footer (closing `{quote}`), plus truncation `head`/`tail` blocks.
  - Budget the remaining characters for `comment["body"]`.
  - Reconstruct: `trunc_head + formatted_prefix + '{quote}\n' + truncated_body + '\n{quote}' + trunc_tail`.
2. If you keep truncating formatted text, **ensure balanced markup** at minimum:
  - Detect an odd count of `{quote}` markers after truncation and append a closing `\n{quote}` before the truncation tail.
  - Guard against cutting *inside* a `{quote}` token (e.g., trim back to the last complete token boundary).
3. **Add/adjust tests** to cover truncating a string that contains `{quote}` markers (i.e., the real `_comment_format()` output), asserting the output contains a closing `{quote}` before the truncation tail and remains <= `JIRA_COMMENT_BODY_MAX_CHARS`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[webbnh]

This is a great first pass, but there are a few things that you should attend to.

• I assume that the PR description body is subject to the same constraints as the comments, so I think we should be prepared to truncate that, too.
• Handling a crazy-long URL is an excellent piece of defensive coding, but I think we can be more strategic and graceful in how to do it.
• I think we should leave some "head room" in (or outside) the budget for add-ons that we're not anticipating (I called out a couple of them) so that we don't fail on edge cases.
• And, I think we have a couple more things that the unit tests should assert.