Repository navigation
[Bug]: jira workitem update --comment hangs and grows to 13 GB+ memory on one specific issue #25
Description
TWG CLI version
1.3.5 (also reproduced on 1.3.3, before upgrading)
Operating system
macOS 26.6.1 (arm64, Apple Silicon); installed with the direct public installer
Command or agent request
Run non-interactively by an AI coding agent, but reproducible from a plain shell:
twg jira workitem update --site <site>.atlassian.net --id <PROJECT-KEY> \
--comment "<markdown, ~700 chars>" --comment-format markdown -o jsonThe markdown comment is ordinary. It has a bold lead-in, a 3-item bullet list with inline code, a 4-row pipe table, double quotes and an en dash. The same kind of comment, tables included, posts fine on other issues in the same project.
A status transition on the same issue showed the same behaviour:
twg jira workitem update --site <site>.atlassian.net --id <PROJECT-KEY> \
--status "Done" --transition-comment "<markdown>" --transition-comment-format markdown -o jsonExpected behavior
The comment (or transition) is applied within a few seconds and the process exits, using a modest amount of memory, as it does for other issues.
Actual behavior
On one particular issue, every attempt that adds a comment hangs, and memory grows without bound:
| Attempt | Version | Command | Observation |
|---|---|---|---|
| 1 | 1.3.3 | update --status Done --transition-comment … |
Ran 2 h 40 m at ~0.5 GB RSS, never exited; killed |
| 2 | 1.3.3 | update --status Done (no comment) |
Succeeded in about a minute; the issue moved to Done |
| 3 | 1.3.3 | update --comment … (same text as 1) |
Hung past a 90 s timeout; killed |
| 4 | 1.3.3 | update --comment … |
Hung; killed with SIGKILL |
| 5 | 1.3.5 | update --comment … |
13.5 GB RSS after 52 s, still growing; killed |
So on this issue, the plain transition works; anything that adds a comment (--comment, or --transition-comment) hangs.
A separate, unrelated twg jira workitem … process was also found at 2.9 GB RSS after 2 h 36 m on 1.3.3. The machine became noticeably unresponsive from these processes.
Observations that may help narrow it down:
- The issue itself is unremarkable: standard Story/Task fields, a few comments, recently transitioned to Done.
getJiraIssuereturns it instantly. - The same payload works through another client: the identical comment body, posted to the same issue through Atlassian's own Jira MCP connector (
addOrEditJiraIssueComment), succeeded immediately. - Other issues in the same project work with twg 1.3.5, including comments with markdown tables and status transitions. Only this one issue reproduces it, deterministically.
- No output is printed before the hang, with
-o jsonand stdout/stderr redirected. I didn't find a verbose or debug flag to capture more. If there is one, I'm happy to rerun with it. - A plain
timeout 90doesn't always stop it: in one case the childtwgprocess outlived itstimeoutwrapper and neededkill -9.
I can share the issue key and the exact comment body privately with a maintainer if that would help reproduce it.
Activity
SourceCode commentedon Oct 10, 2026
I have also had this process run as high as 52Gb and 46Gb of consumed memory in separate threads that I had to kill with SIGKILL - so while 13Gb was the latest round - it will ultimately consume all the memory of the machine if left unattended.
Two nights of this week I had loads of failed processes and while I can't connect it directly to twg I believe this to be the cause.
I am using twg heavily in my workflows now and will report if I see this on linux or windows as well.
SourceCode commentedon Oct 10, 2026
Investigation update: this is reproducible from the Markdown payload, independently of the particular Jira issue.
The trigger is the pipe table indented two spaces under the final bullet item. With the original payload, TWG CLI 1.3.5 exceeded a 512 MiB watchdog limit in 1.50 seconds and printed no output. A sanitized payload with the same structure reproduced it in 1.41 seconds. Removing the table's two-space indentation (and putting the paragraph after it at column zero) let the CLI proceed in under a second.
These checks used deliberately nonexistent numeric issue ID
0. The dedented case reached the expected HTTP 404 on issue lookup, before any comment could be posted. No Jira issue was changed.The failure is in CLI-side Markdown/rich-text conversion. Both
--commentand--transition-commentshare that conversion path. The bundled table parser reuses parent line/indentation state for each cell and setslineMax = 1while tokenizing later document lines. Separate offline tests of that parser pattern produce a non-advancing ordered-list loop and bounded heap exhaustion. This is the implementation lead to investigate in the private source, rather than the issue's status or existing comments.Verified workaround: end the list with a blank line and put every pipe-table line at column zero. Also dedent the paragraph following the table. Offline conversion of the dedented original preserved all three list items and all nine data cells. A live comment write/transition was not tested.
Draft documentation PR: #26. It includes a public-safe reproducer, measurements, and regression requirements. This public repository has no CLI implementation source, so the PR documents the workaround; it does not fix the executable or close this bug. The implementation fix must also prevent silent content loss, not just stop the memory loop.