Skip to content

fix(cli): prevent UTF-8 panic in explore table wrapping (3.2.3)#52

Merged
montfort merged 1 commit intomainfrom
chore/bump-cli-3.2.3
Apr 24, 2026
Merged

fix(cli): prevent UTF-8 panic in explore table wrapping (3.2.3)#52
montfort merged 1 commit intomainfrom
chore/bump-cli-3.2.3

Conversation

@montfort
Copy link
Copy Markdown
Contributor

Summary

  • Fix devtrail explore panic (byte index N is not a char boundary) when Markdown tables contain multi-byte UTF-8 characters (em-dash , CJK, accents, emoji). wrap_cell_text() now iterates with char_indices() and measures width via unicode-width, guaranteeing safe slice offsets and correct visual widths.
  • Align table borders under CJK / double-wide content by padding cells by visual width in render_table_row() instead of format!("{:<width$}", ...) (which counts chars, not columns).
  • Add 16 unit tests, including a regression (em_dash_no_panic) that reproduces the original crash and an end-to-end test running the exact table row that triggered it through markdown_to_lines.
  • Bump CLI to 3.2.3. unicode-width = "0.2" promoted to a direct optional dep under the existing tui feature (was already transitive via ratatui, so no new compile cost).

Reproduction

Running devtrail explore on a document containing this table row used to panic:

| E-003 | … | Admin role required. RLS middleware adds tenant isolation at DB layer. **Partially mitigated** — RLS is not active until Auth middleware is connected (Etapa 4). |

After this patch the view renders the table without panic and with aligned borders.

Test plan

  • cargo test — 64 library tests passing (48 pre-existing + 16 new tui::markdown::tests::*).
  • cargo build --no-default-features — compiles (feature gate on unicode-width is respected).
  • cargo build --release — compiles; ./target/release/devtrail about reports cli-3.2.3.
  • cargo clippy --all-features — no new warnings from this patch (6 pre-existing warnings in files not touched here).
  • Manual: ./target/release/devtrail explore <path-with-problematic-doc> opens the document without panic.
  • Manual: a table mixing ASCII, CJK and emoji renders with aligned borders.

Files changed

  • cli/Cargo.toml — bump to 3.2.3, add unicode-width under feature tui.
  • cli/Cargo.lock — regenerated (adds unicode-width as direct dep; same version already present transitively).
  • cli/src/tui/markdown.rs — rewrite wrap_cell_text, fix visual-width measurement in compute_column_widths and render_table_row, add 16 tests.
  • CHANGELOG.md## CLI 3.2.3 — UTF-8 Crash Fix in explore Tables section.
  • README.md, docs/i18n/es/README.md, docs/i18n/zh-CN/README.md — versioning table bump.
  • docs/adopters/CLI-REFERENCE.md and its es/ + zh-CN/ mirrors — version refs bumped.

🤖 Generated with Claude Code

`devtrail explore` panicked with `byte index X is not a char boundary`
when rendering Markdown tables whose cells contained multi-byte UTF-8
characters such as em-dash (U+2014, 3 bytes), CJK ideograms, accented
characters or emoji. The cause was `wrap_cell_text()` slicing `&str`
by a byte offset derived from terminal columns.

Fix:
- Rewrite `wrap_cell_text()` to iterate with `char_indices()` so every
  slice boundary is a valid char boundary.
- Measure text width with `unicode-width` (added as a direct dep under
  the existing `tui` feature; was already a transitive dep of
  `ratatui`, so no new compile cost) so wrapping and natural column
  widths match the visual columns ratatui reserves at render time.
- Manually pad cells by visual width in `render_table_row()` instead
  of `format!("{:<width$}", ...)`, which counts chars, not columns —
  this also aligns borders for CJK / double-wide content (relevant for
  the zh-CN docs the project ships).
- Add 16 unit tests, including a regression for the exact panic
  (`em_dash_no_panic`) and an end-to-end pipeline test using the
  literal row that crashed the reported document.

Bump CLI to 3.2.3.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@montfort montfort merged commit bb2a905 into main Apr 24, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant