Repository navigation
Conversation
|
✅ DCO Check Passed Thanks @Eapp1e, all your commits are properly signed off. 🎉 |
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
AI triage (advisory)Checked commit This pull request counts the header row in the chart table cell limit. It adds tests for CI safety: no concern found. A maintainer must still approve CI. The |
`build_chart_table` capped the emitted table with data rows only, then added the header row outside the bound. A truncated table therefore still exceeded `MAX_CHART_TABLE_CELLS`, and a table that landed exactly on the cap was not truncated at all. Both the trigger and the bound now include the header row, and the warning reports the same total. The pptx test that pinned the old arithmetic asserts the documented bound instead. Signed-off-by: Eapp1e <163811520+Eapp1e@users.noreply.github.com>
908310a to
ad61389
Compare
There was a problem hiding this comment.
AI first review (advisory): no blocker found
This review covers the full diff at ad61389002. It read the code and did not run it.
The fix correctly counts the header row in both the cap trigger and the bound computation. The arithmetic is sound, the two tests cover the two defect cases, and all assertions match the patched values. No issues found.
A maintainer makes the merge decision. This review never approves the pull request.
Fixes #5029
Problem
build_chart_table()documents that the emitted table is capped atMAX_CHART_TABLE_CELLScells. The constant itself is described as a backstop on the total cells emitted for one chart.The cap arithmetic counts data rows only. The header row is emitted afterwards and is never counted. This causes two defects:
50000 * 2 = 100000, so100000 > 100000is false. The header row then pushes the table to 100002 cells, without a warning.Fix
Count the header row in both the trigger and the bound:
The warning now reports the same total, including the header row.
Tests
tests/test_backend_pptx.py:test_chart_data_table_capped_at_max_cellsnow expectsMAX_CHART_TABLE_CELLS // 3 - 1data rows and assertslen(table.table_cells) <= MAX_CHART_TABLE_CELLS. The previous assertion (// 3, then+ 1row) required 100002 cells, so it pinned the defect instead of the documented bound.test_chart_data_table_cap_reached_exactlyis new. It covers a table that lands exactly on the cap, where the old code produced no warning and 100002 cells.Both new assertions fail on current
mainand pass with the change:Limits
When the column count alone exceeds the cap (a chart with 50000+ series), the header row still exceeds it. Only column truncation can fix that case. This change does not touch it.
The xlsx chart reader (
docling/backend/msexcel_backend.py) uses the same data-row-only arithmetic. I left it unchanged to keep this PR small. I can send a follow-up for it if you want.