[breken-ai]

Update (2026-10-07): #4488 moved Markdown table parsing to marko's GFM extension, and that fixes the bug below on main. This PR now adds only the regression test. The original backend change has been dropped.

The bug (fixed on main by #4488): the Markdown backend dropped a line of text when a paragraph started with a pipe but had no GFM delimiter row. _close_table always threw away the second buffered row, assuming it was the |---|---| delimiter row. This shows up with Pandoc line blocks (addresses, verse) and with pipe tables written without a delimiter row:

Ship to:

| Jane Doe
| 221B Baker Street
| London NW1 6XE

Before #4488, export_to_markdown() gave a two-row table and the street line was gone. | a | b | / | 1 | 2 | / | 3 | 4 | lost 1 | 2 in the same way.

Change: test_convert_leading_pipe_lines_without_delimiter_row_keep_all_text checks that pipe-led lines with no delimiter row stay one text item with every line kept, and that no table is built. It covers a delimiter-less pipe table and a pipe-led line followed by plain text.

Tests:

• On 1a264db~1 (just before feat(md): preserve inline formatting in Markdown table cells #4488): fails with assert [TableItem(...)] == [].
• On main (213288f) with this commit: tests/test_backend_markdown.py passes, 34 of 34.
• ruff check and ruff format --check are clean on the test file.

I found this with help from an AI coding assistant, and I reviewed the test and its results myself.

Checklist:

• Documentation has been updated, if necessary.
• Examples have been added, if necessary.
• Tests have been added, if necessary.

[github-actions]

✅ DCO Check Passed

Thanks @breken-ai, all your commits are properly signed off. 🎉

[mergify]

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ceberam]

Thanks @breken-ai for spotting this issue. The bug is real and the diagnosis is accurate.
The fix is correct, well-scoped, and does not regress existing behavior.
Please, address the inline comment and the PR will be ready to be merged.

[ceberam]

The first sentence is useful: it states the GFM rule. The second sentence explains what the old, buggy code did, not what a future maintainer needs to know. It should be removed or rewritten to describe the invariant. For example:

Suggested change

	# GFM: a table needs a delimiter row right after its header, so
	# lines that merely start with a pipe are a paragraph. Building a
	# table here would drop the second line, taken for that row.
	# GFM: a table requires a delimiter row immediately after its header.
	# Without one, lines that start with a pipe are ordinary paragraph text.

[breken-ai]

Applied your wording in the test docstring (4361aea). The _close_table change itself is gone, because #4488 replaced that parsing path. Details in the PR conversation.

[ceberam]

@breken-ai Please check the PR #4488
I have refactored the table parsing to leverage marko GFM extension. Instead of a manual string manipulation to parse tables (and the challenges to deal with complex edge cases like this one), we can leverage the Markdown(extensions=["gfm"]):

• marko natively understands the GFM Table specification.
• The parser itself produces a clean, structured tree of table nodes.

I checked and with that approach the case in this PR is no longer an issue, since marko does not recognize Pandoc line blocks as tables.

[breken-ai]

@ceberam thanks, I checked #4488 and you're right. With the marko GFM parser, pipe-led lines that have no delimiter row are no longer read as a table.

• Before feat(md): preserve inline formatting in Markdown table cells #4488 (1a264db~1): | a | b |\n| 1 | 2 |\n| 3 | 4 | builds one table and loses 1 | 2. | quoted note\nsecond line also builds a table.
• On main (213288f): both come back as a single text item with every line kept, and no table is built.

So I've dropped the _close_table change, since that code path no longer exists after #4488 and the branch conflicted with it. The PR is now test-only (4361aea). It keeps test_convert_leading_pipe_lines_without_delimiter_row_keep_all_text as a regression guard for the new parser. The docstring uses your wording and describes the invariant.

• It fails on 1a264db~1 with assert [TableItem(...)] == [] and passes on main.
• tests/test_backend_markdown.py passes, 34 of 34. ruff check and ruff format --check are clean.

If you'd rather not take the extra test, feel free to close this.

[github-actions]

AI triage (advisory)

Checked commit 4361aeaa46. The analysis read the diff only. It did not run code from this pull request.

This PR adds a regression test that checks pipe-led lines without a GFM delimiter row are kept as plain text with no lines dropped and no table created. The underlying bug was already fixed by PR #4488.

Topic labels added: markdown, tests.

CI safety: no concern found. A maintainer must still approve CI.

1 related pull request(s) in the same code

PR	State	Signal	Assessment
#4488	merged	referenced as #4488	related: PR #4488 (merged) fixed the bug and added extensive inline-formatting tests for the Markdown table backend. This PR adds only a focused regression test for the pipe-led-lines-without-delimiter-row case that #4488 also fixed; they touch the same file but do different things and neither blocks the other from being merged.

_{The ai:* labels are advisory. They do not approve CI and they do not add tests:full. A new push runs this check again.}

[github-actions]

AI first review (advisory): no blocking issue found

This review covers the full diff at 4361aeaa46. It read the code only. It did not run tests or code from this pull request.

This PR adds a single regression test test_convert_leading_pipe_lines_without_delimiter_row_keep_all_text to tests/test_backend_markdown.py. It guards against a bug (fixed on main by PR #4488) where _close_table dropped one buffered row when pipe-led lines had no GFM delimiter row. No production code is changed. The main risk is that the two hardcoded expected strings depend on marko's exact soft-line-break join behavior; a change in marko's internal representation could cause spurious failures.

_{A maintainer makes the merge decision. This review never approves the pull request.}

[github-actions]

minor: Expected strings are brittle against marko's join representation

The expected value "| a | b | | 1 | 2 | | 3 | 4 |" is derived from the backend joining lines with a single space (soft-break path at md_backend.py:898). This is currently correct, but any change in marko's tokenisation of pipe-surrounded text — for example if marko ever strips leading/trailing pipes from non-table paragraph lines — would silently produce a wrong expected value rather than a meaningful failure message.

Consider adding a brief comment to the tuple explaining the join rule:

Suggested change

	("| a | b |\n| 1 | 2 |\n| 3 | 4 |\n", "| a | b | | 1 | 2 | | 3 | 4 |"),
	# Lines are joined by the soft-break path (md_backend.py) with a single space.
	("| a | b |\n| 1 | 2 |\n| 3 | 4 |\n", "| a | b | | 1 | 2 | | 3 | 4 |"),

[github-actions]

minor: document.texts includes CodeItem; unfiltered list comparison may mask future regressions

DoclingDocument.texts is a flat list that includes CodeItem instances alongside TextItem instances (see test line 270 which filters isinstance(item, CodeItem)). For the current inputs this is harmless — no code spans are present — but if the test inputs were ever extended with backtick content, the unfiltered assertion would produce a confusing failure. Consider adding an isinstance guard or a comment explaining that the assertion intentionally covers all text-like items for these inputs.

[github-actions]

nit: Pandoc line-block format from the PR description is not covered

The PR body uses a Pandoc address example (| Jane Doe\n| 221B Baker Street\n| London NW1 6XE\n) as the primary motivating case, but the test uses abstract | a | b | rows. Adding the address-format case (or a comment linking the motivation) would make the regression guard easier to understand when it fails in the future.

[ceberam]

Closing as agreed on #4454 (comment)