[Bug]: markdown_to_jira (Server/DC wiki path) leaves bare curly braces unescaped and breaks inline code containing braces

[dkodr]

Environment

• mcp-atlassian 0.23.0 (uvx, PyPI)
• Jira Server 9.4.1 (self-hosted, wiki markup path — not Cloud/ADF)

Summary

On the Server/DC path, JiraPreprocessor.markdown_to_jira produces wiki markup that the
Atlassian wiki renderer mangles whenever the input contains curly braces. Two distinct cases:

1. Bare braces in plain text are passed through unescaped.
The wiki renderer treats any bare {...} as a macro attempt and splits the paragraph.

Input (Markdown): Filter {a: 1} and JSON {"key": "val"} in text
Converter output: unchanged (no escaping)
Rendered HTML (Jira 9.4.1, atlassian-wiki-renderer):
<p>Filter </p> {a: 1} <p> and JSON </p> {"key": "val"} <p> in text</p> — paragraph broken.
Worse with macro-like names: Use {code} or {color:red} here injects an empty code panel
and swallows text.

2. Inline code containing braces is wrapped into invalid nested braces.
Input: Selector `{"id": "default"}`
Converter output: Selector {{{"id": "default"}}}
Rendered: <p>Selector {{</p> {"id": "default"} <p>}}</p> — the parser reads the inner
{...} as a (broken) macro and explodes the fragment. This is the wiki-path counterpart
of #1340 (which covers the Cloud/ADF converter).

Expected behavior

Both render as literal text / monospace. Verified working forms on Jira Server 9.4.1:

• plain text: backslash escapes — Filter \{a: 1\} renders as Filter {a: 1} (clean <p>)
• inline code: HTML entities inside monospace — {{{"id": "default"}}} renders
  as full <tt>{"id": "default"}</tt>

Suggested fix

In markdown_to_jira (wiki path only; ADF path unaffected):

1. after extracting fenced/inline code blocks, escape remaining bare { / } as \{ / \}
   (analogous to the intraword-underscore escaping added in fix(jira): don't italicize intraword underscores in markdown_to_jira #1361),
2. for inline code spans, emit { / } for braces inside the {{...}} wrapper
   instead of raw braces.

One design consideration: some users may intentionally pass raw Jira macros ({code},
{panel}) through Markdown input — escaping should whitelist balanced known macros or be
opt-out.

I can share full render-endpoint evidence (POST /rest/api/1.0/render) for all cases if useful.

[ebarkhordar]

Both converter outputs reproduce on current main (31c1d77), not just the 0.23.0 wheel. Clean
python:3.12-slim container, pip install -e ., calling JiraPreprocessor.markdown_to_jira
directly:

IN : 'Filter {a: 1} and JSON {"key": "val"} in text'
OUT: 'Filter {a: 1} and JSON {"key": "val"} in text'

IN : 'Use {code} or {color:red} here'
OUT: 'Use {code} or {color:red} here'

IN : 'Selector `{"id": "default"}`'
OUT: 'Selector {{{"id": "default"}}}'

The {{{...}}} in the third case comes from _md_inline_to_jira at
src/mcp_atlassian/preprocessing/jira.py:453, which is an unconditional
"{{" + match.group(1) + "}}" around the captured span.

I cannot confirm the rendered HTML you quoted: there is no Jira Server 9.4.1 here, so the render
half of your report is unverified on my side and I am only speaking about what the converter emits.

Two things that bear on your design question about deliberate macro passthrough.

The test suite does not depend on it. Every assertion in the suite that expects a Jira macro is
about a macro the converter itself produces from a fenced block (19 of them, all {code} or
{code:<lang>}); none asserts that a macro typed into the Markdown input survives to the output.
So escaping bare braces would not turn the suite red, which means the risk you named is a question
about undocumented caller habits and not about a covered behaviour.

There is also no recorded decision to protect it. On an unshallowed clone, git log -G over the
inline-code wrapper returns one commit (fcc5c90, #1066, the placeholder-helper refactor), and
\{ in this file returns four, all in the other direction: {panel} and {code} parsing inside
jira_to_markdown (70c1869, c24bbfb, fcc5c90, ae88cc2). Nothing ever added brace escaping
to the Markdown-to-wiki path and nothing removed one, so the passthrough looks unhandled rather
than chosen. Your #1361 precedent is the closest thing to a prior decision here and it went the
other way, toward escaping.

One correction on the cross-reference: #1340 is about underscores being eaten inside inline code
spans, not braces, so this is not the wiki-path counterpart of it. As far as I can find, the brace
case has not been reported before.

[dkodr]

Thanks for the thorough verification — the clean-container repro on main and the git log -G archaeology are exactly the pieces my report was missing.

You're right about #1340, thanks for the correction — it's about underscores inside inline code on the Cloud/ADF path, not braces, so it isn't the wiki-path counterpart I made it out to be.

To close the render half you flagged as unverified on your side: I just ran your three exact converter outputs through POST /rest/api/1.0/render (atlassian-wiki-renderer) on a live Jira Server 9.4.1, plus the escaped variants proposed in the report for contrast:

IN : Filter {a: 1} and JSON {"key": "val"} in text
OUT: <p>Filter </p> {a: 1} <p> and JSON </p> {"key": "val"} <p> in text</p>

IN : Use {code} or {color:red} here
OUT: <p>Use </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"></pre> </div></div> <p> or <font color="red"></font> here</p>

IN : Selector {{{"id": "default"}}}
OUT: <p>Selector {{</p> {"id": "default"} <p>}}</p>

So: bare braces split the paragraph, macro-shaped text injects an empty code panel and swallows the color argument, and the nested {{{...}}} breaks the paragraph instead of rendering monospace. The escaped forms all render clean:

IN : Filter \{a: 1\} and JSON \{"key": "val"\} in text
OUT: <p>Filter {a: 1} and JSON {"key": "val"} in text</p>

IN : Use \{code\} or \{color:red\} here
OUT: <p>Use {code} or {color:red} here</p>

IN : Selector {{&#123;"id": "default"&#125;}}
OUT: <p>Selector <tt>&#123;"id": "default"&#125;</tt></p>

Given your finding that the test suite doesn't depend on macro passthrough (all 19 macro assertions cover macros the converter itself emits from fenced blocks) and that there's no recorded decision protecting the passthrough, I'd be glad to put together a PR along the lines proposed above — escape bare braces as \{/\} in plain text and use HTML entities inside inline-code spans — if the maintainers are open to that direction.