[davsclaus]

Stacked on #28220. CAMEL-25892 brought the body types each step of a route has been reached with to the Routes and Diagram tabs of the Camel TUI. This is its third view, the source view of the Source tab (CAMEL-25897):

• At the end of the line of each step: its body types, dimmed and lined up, cut to the room there is (ByteArrayInputStreamCache, ⚠ LinkedHashMap | InputStreamCache).
• A ⚠ in the gutter of a step reached with bodies of more than one kind (null, payload, data or collection), whose types are in the warning color: its body depends on the path a message takes.
• The quick documentation of the line lists all the types, and for a mix of kinds says why it needs attention.

Only for the version of the file that runs. The facts of a line hold only while the view has the file as the integration runs it. #28220 added the run state of the open file. The live run data is dimmed, and the body types are left out:

• while the integration does not run the file as saved: saved after it loaded the file, reloading, or the reload failed;
• until the run state is known for the file shown: after another file is opened, or the file is saved in the editor. Both compute the state at once, in the background.

A file whose routes are all stopped (or suspended) shows ○ the routes of this file are stopped. Its live run data and body types still show when the integration loaded the file as saved. Without a reload that is known, as the routes were loaded at the start. After a reload, when a stopped route was loaded is not known, so they are left out.

The issue asked to keep the body types of the routes an edit did not change, by their checksums. The TUI cannot compute the checksums of an edited YAML or XML file without loading it with Camel, which runs parts of it and needs the components (see #28220). So the view leaves them all out until the integration runs the file. In dev mode that is about a second after a save, and they come back as messages reach the new steps.

How

• LiveRunLines collects the body types of the steps on each line with the live run data. A line is mixed when one of its steps was reached with more than one kind. Two steps on one line that each have a kind of their own do not make it mixed.
• SourceLiveColumn draws the gutter mark and the types after the code, and gives the quick documentation entry. The types are cut one column before the scrollbar's. SourceViewer only calls it, and stays within its size limit.
• The live run data is read again as soon as another file is shown, not up to a second later.

Tests

• SourceBodyTypesTest:
  • the types at the end of the step lines, lined up, and the ⚠ in the gutter only on the mixed step;
  • cut to a narrow view;
  • none in plain mode;
  • none, with the live data dimmed and no runtime failure offered to fix, while the integration runs another version;
  • the quick documentation;
  • the steps of one line together;
  • a save in the editor hides them until the next refresh;
  • a cut name keeps its … and a count its digit, from 44 to 72 columns;
  • another file has its own live run data at once, and is stale until its state is known.
• SourceRunStateTest: a file whose routes are all stopped, before and after a reload.
• The camel-jbang-plugin-tui suite: 2228 tests pass.
• Checked live with an integration in dev mode whose choice marshals in one branch:
  • the four steps after the choice have the ⚠ and their two kinds;
  • after an edit, the body types go away while the integration reloads, and come back with the new steps.

Docs: the Source help page, and the Source Editor and Diagram pages of the manual, with the screenshot.

Claude Code on behalf of davsclaus

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet-bot]

This is a clean, well-tested feature. The 7 test cases cover the full feature lifecycle: alignment and gutter marks, narrow-viewport truncation, plain mode, stale/dirty state dimming, quick-doc content, multi-processor-per-line aggregation with correct mixed semantics, and the save-stale-refresh state machine.

A few design notes worth having on record:

BodyTypes.mixed(null) is null-safe. The call in LiveRunLines.addBodyTypes() passes p.bodyKinds which can be null, but BodyTypes.mixed() has an explicit null guard (return kinds != null && kinds.size() > 1) — null input returns false, which is correct (no kinds = not mixed).

Threading is correct. bodyTypesAlign is written in refreshLiveLines() and read in addBodyTypes() — both on the render thread, following the same single-render-thread pattern as the existing liveTotalWidth/liveFailedWidth/liveMeanWidth fields. No volatile needed. Similarly, wasDirty in SourceRunState.Tracker is read and written exclusively from the UI thread in shown() — refresh() on the background thread never touches it.

gutter() / addBodyTypes() consistency. Both call current() which reads volatile saves/computedSaves. A background refresh could flip current() between the two calls, but this produces at most a one-frame visual glitch (gutter mark with no type list, or vice versa) — harmless in a TUI, not a correctness issue.

Progressive degradation in BodyTypes.fit(). The fallback chain (full label → short label → first N types + count → truncated first type + count → just the mark → empty) handles all viewport widths gracefully, which is validated by the narrow-view test (theTypesAreCutToTheRoomThereIs at 56 cols).

Save-stale semantics. The aSaveInTheEditorLeavesThemOutUntilTheIntegrationIsSeenToLoadIt test correctly verifies that after refresh(), stale() still returns true because state.kind() != Kind.RUNNING — body types remain hidden until the integration actually loads the new file version, not just until the next refresh cycle.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[oscerd]

TL;DR

A careful third view of the body types: they come only from the integration's status, nothing loads the route file, and the run state from #28220 hides them while another version runs. No code blocker. Two display gaps and the CI gap are worth closing first.

Blockers

• None in the code. Merge precondition: this PR is stacked (base feature/CAMEL-25771-route-checksum-views, on #28220 → #28213), so Build and test, doc validation and the license check never ran on 8a4c917d6339. Only Dependency Review and PR id uploader did. Let's get a completed build once it targets main.

Other findings: 4 (2 non-blocking, 1 suggestion, 1 question)

1. Cut types lose their last column (SourceViewer.java:2952). The right edge is viewportWidth + hSkip, and viewportWidth is contentArea.width() (:1878). But the paragraph is drawn in hChunks.get(0), which is one column narrower because the last column is kept for the scrollbar (:1883-1888). When BodyTypes.fit cuts a name, truncateWithEllipsis fills the room exactly (BodyTypes.java:114). The … or the last digit of +N then lands in that column and is clipped: ByteArra… shows as ByteArra, which reads like a whole name. Passing viewportWidth - 1 + hSkip fixes it and keeps wrapRowCount consistent. The 56-column test stops at ⚠ byte[] +1, well before the edge. A narrower render that reaches the cut, asserting the … and the +1, would cover it.
2. An unknown run state counts as current (SourceRunState.java:242). stale() is false whenever current() is null for a reason other than a save. One case is a state computed for another file: this lasts until the next refresh after switching files, while liveLines() can still serve the previous file's map for up to a second (SourceLiveColumn.java:257). The other is of() finding no Started route from the file (:95, all stopped or suspended). In that case, with a plain camel run (its default dev profile turns the message history on, and nothing reloads), a saved edit shows the old types and ⚠ on the new lines again after the next refresh, undimmed. What do you think about these three changes? Treat "not computed for the file shown" as stale (keep Computed(shown, null) so it differs from "no started route"). Re-read liveLines() when the file changes. And decide what a file whose routes are all stopped should show.
3. [Suggestion] Jira scope. CAMEL-25897 still says the routes an edit did not change keep their hints through the CAMEL-25771 checksum, and the PR explains why it leaves that out. Could we update the issue text, or open a follow-up, before resolving it?
4. [Question] Gutter ⚠. The mark for a mixed body kind is the same glyph and style as the deprecated-line mark (SourceViewer.java:2935, " ⚠ " in Theme.warning()), and a deprecated line shows only that one. Is sharing it intended, or would a distinct style help tell them apart?

Reviewed with Claude Code on behalf of oscerd. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

[davsclaus]

Thanks. These are addressed in 3101f32, after merging the updated #28220 branch in.

CI: as for #28220, Build and test runs once this PR targets main, after #28213 and #28220.

1. Fixed. The right edge is now viewportWidth - 1 + hSkip, as the last column is the scrollbar's. aCutNameKeepsItsEllipsisAndTheCountItsDigits renders 44 to 72 columns and checks that every cut name keeps its … and every count its digit. Without the fix it fails at 45 columns.
2. Done, all three:
   • A state not computed for the file shown counts as stale. For a file the integration has no route from, the tracker keeps Computed(file, null), which is not stale. Showing another file, or saving it, computes the state at once in the background, so the gap is a frame rather than a second. A refresh that started later wins over one that ends after it.
   • liveLines() reads the data again as soon as the file shown changes. anotherFileHasItsOwnLiveRunDataAtOnce fails without it.
   • A file whose routes are all stopped (or suspended) now has a state of its own: ○ the routes of this file are stopped.
     • Its live run data and body types still show when the integration loaded the file as saved. Without a reload that is known, as the routes were loaded at the start.
     • After a reload, when a stopped route was loaded is not known, so they are left out.
     • A file saved since the integration loaded it says not running yet, stopped or not.
3. Done. The description of CAMEL-25897 now says the checksum part is out of scope, and why, and a comment points to this PR.
4. Intended. ⚠ is the mark of a mixed body kind in every view (Routes, Diagram and the Camel CLI). The types at the end of the line carry it too, in the warning color. A line with a deprecated option takes the gutter as before, and its body types still show the ⚠. The quick documentation of the line says which one it is. A glyph of its own in the gutter would make the mark differ between the views.

Claude Code on behalf of davsclaus

[gnodet-bot]

Following up on my earlier review — all 4 of oscerd's findings have been addressed in 3101f32.

[1] Right-edge off-by-one — ✅ Addressed. viewportWidth - 1 + hSkip at SourceViewer.java:2952 is correct; the new aCutNameKeepsItsEllipsisAndTheCountItsDigits test validates the fix across 44–72 column widths, asserting the … and the +N digit are preserved at every width.

[2] Unknown run state — ✅ Addressed. Three separate fixes:

• Computed(file, null) is now stored for the file shown but with no started route, so stale() correctly returns true until the next refresh() computes it — the gap is a single frame.
• liveLines() re-reads immediately when liveLinesFile differs from loadedFilePath, eliminating the up-to-one-second lag on file switch.
• Kind.STOPPED handles the all-stopped-routes case; state.stale() is 0 when routes were loaded as saved (body types visible), and is incremented for routes stopped after a reload (body types hidden). All three sub-cases have test coverage in SourceBodyTypesTest.

[3] JIRA scope — ✅ Confirmed by author.

[4] Gutter ⚠ glyph — ✅ Confirmed intentional; consistent with Routes and Diagram tabs.

Pre-fix validation (static trace): anotherFileHasItsOwnLiveRunDataAtOnce asserts immediate data switch after viewer.loadFile(other), which exercises the liveLinesFile check added in refreshLiveLines(). aSaveInTheEditorLeavesThemOutUntilTheIntegrationIsSeenToLoadIt verifies the saves/computedSaves tracking. Both tests would pass without the fix only if the data happened to load within the assert's frame — not the case given the synchronous refreshLiveLinesForTesting() helper.

The Tracker concurrency model is sound: shown() and stale() are UI-thread-only; saves is volatile and written only on the UI thread; the synchronized block in refresh() guards computed/written/computedSaves; and the AtomicLong refreshes ordering ensures a later refresh always wins over an earlier one that ends after it.

LGTM.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[github-actions]

🧪 CI tested the following changed modules:

• docs
• dsl/camel-jbang/camel-jbang-plugin-tui

---

🔬 Scalpel shadow comparison — Scalpel: 2 of 707 tested, 1 compile-only — current: 2 all tested

Maveniverse Scalpel detected 2 affected modules (current approach: 2).

Skip-tests mode would test 2 modules (2 direct + 1 downstream), skip tests for 1 (generated code, meta-modules)

Modules Scalpel would test (2)

• camel-jbang-plugin-tui ← dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/LiveRunLines.java, dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/SourceLiveColumn.java, dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/SourceRunState.java, dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/SourceTab.java, dsl/camel-jbang/camel-jbang-plugin-tui/src/main/java/org/apache/camel/dsl/jbang/core/commands/tui/SourceViewer.java, dsl/camel-jbang/camel-jbang-plugin-tui/src/main/resources/tui/help/source.md, dsl/camel-jbang/camel-jbang-plugin-tui/src/test/java/org/apache/camel/dsl/jbang/core/commands/tui/SourceBodyTypesTest.java, dsl/camel-jbang/camel-jbang-plugin-tui/src/test/java/org/apache/camel/dsl/jbang/core/commands/tui/SourceRunStateTest.java
• camel-launcher-container ← downstream of org.apache.camel:camel-launcher

Modules with tests skipped (1)

• camel-launcher

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (4 modules, 40.5s total)

Total reactor time: 40.5s

Module	Duration	Status
Camel :: Launcher	26.8s	SUCCESS
Camel :: Docs	13.0s	SUCCESS
Camel :: Launcher :: Container	0.7s	SUCCESS
Camel :: JBang :: Plugin :: TUI	n/a

Top 20 slowest modules:

• Camel :: Launcher (26.8s)
• Camel :: Docs (13.0s)
• Camel :: Launcher :: Container (0.7s)

---

⚙️ View full build and test results