Repository navigation
Focus the state machine on the rejected call - #158
Merged
Merged
Conversation
When the State Machine view is opened from a state refinement error, start with a reduced diagram of the found state, the required states, and the states on a shortest path between them. The rejected call is a note on the found state instead of a highlighted transition, so it never reads as a successful transition, and it is shown even when the method is absent from the general diagram or merged into another label. A summary lists the rejected call, Found, and Required with icons and text, and a button toggles between the focused and the full diagram. The view uses the receiver, expected states, conditions, and definite found state from the liquidjava-fsm error context. When Found is not one definite state, the found condition is shown without marking a single state. Error contexts without these fields keep the previous highlighting by label. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mermaid draws a state with a description as an outer rect and a divider line rather than a .label-container, so the found, required, and possible state styles only reached the divider. Target the outer rect as well and cover both node shapes with style tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Give a state that may be found and is also required one combined label and style instead of duplicate descriptions. - Keep self loops of the called method on required states in the focused view, since they show where the call is allowed. - Keep the called method highlight in the full diagram; the focused view shows the allowed edge without it. - Let the pan handler ignore the error summary so its text stays selectable. - Enable condition expansion only for the transitions actually displayed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 24, 2026
Rework the state error view into a minimal overlay on the full diagram. Given the receiver's possible states and the states the call accepts, possible states that accept the call get a green outline and a check mark, possible states that reject it a red outline and a cross, and the other accepted states a thin dashed warning outline. Every transition of the called method keeps its red label. Focusing on the error dims the states and transitions unrelated to those states, and a single button toggles the dimming. A one line summary says where the call is rejected and where it is allowed. This removes the reduced diagram, the rejected call note, the found condition node, and the state descriptions. The possible states come from the new possibleStates field, falling back to the definite found state or the found states; error contexts without the accepted states keep the previous highlighting. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Do not focus when the call accepts no state of the machine, fall back on empty possible states, and never dim when nothing is related. - When every state is possible, only hint at the accepted states and say that the state of the receiver is unknown. - Dim transitions after rendering from a Mermaid comment instead of wrapping their labels, so unlabeled initial transitions are dimmed without changing the layout between modes. - Keep the zoom and pan when toggling the dimming. - Copy the Mermaid source without the error overlay. - Phrase the summary when every possible state accepts the call. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 24, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Explain the state marks in a one line legend with the same outlines, fills, and icons as the diagram, shown only for the marks present. - In focus mode, dim each method name that neither is the failed method nor leaves a possible state for another state, including names inside merged labels, and dim a transition when all its methods are dimmed. Only styling hooks are added, so the layout matches the plain view. - Darken the dashed outline of the other accepted states in light themes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 24, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- In focus mode, dim the initial transitions too, since the receiver already exists at the failing call. - Clip the diagram to its own viewport so that panning it upwards no longer draws it over the error summary and legend. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The opaque background of a fully dimmed label stood out from its dimmed transition, so make it transparent. Labels with a bright method keep it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 24, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 24, 2026
CatarinaGamboa
added a commit
that referenced
this pull request
Oct 26, 2026
## Description Closes #155. Makes the State Machine view easy to reach from a state error and keeps the error there. Before, the only way in was a small icon on the error in the Verification tab, and clicking the State Machine tab dropped the error, so getting back meant going through the Verification tab again. This replaces the earlier version of this PR, which listed the errors beside the diagram. That worked for one error but crowded the view with several, so the view now shows one error at a time. - **Opens on the first error.** The State Machine tab shows the first state error of the current file, focused, as #158 draws it. - **Keeps the error.** An error chosen with **Show in state machine** or the arrows stays shown after visiting another tab. Opening another file shows its first error instead. - **Follows the cursor.** When the cursor reaches a state error in the editor, the view shows it. A choice made in the view is kept until the cursor reaches another error, and a new verification does not undo it. - **Several errors.** `‹ 1 of 3 ›` steps through the state errors of the current file in source order. The stepper only appears with more than one error. - **Badge.** The State Machine tab shows the number of state errors in the current file. This is the number of **Show in state machine** buttons under *Current file* in the Verification tab, and the `of 3` in the stepper. - **Back to the error.** **View error**, next to the stepper, returns to that error in the Verification tab. The **Show all** / **Focus on error** toggle from #158 now sits with the legend, since it changes the diagram and not the error. - **Way in.** - The `type-hierarchy` icon on state errors is replaced by a labelled **Show in state machine** button at the top of the error, below its title. - State errors also get a **Show in state machine** CodeLens in the editor. It reuses `liquidjava.showView` with an optional `'fsm'` tab argument. - **Re-verification.** - The shown error is matched again by position. If an edit moved it, it is followed only when its call had exactly one error before and after, so it never jumps to a sibling. - Fixed errors disappear. - The diagram only re-renders when what it shows changed, so panning is kept. - **Walkthrough.** The text describes the new flow. ## Screenshots A throwaway copy of the UDP chat client with two more state errors: `bind` on a bound socket and `connect` after `close`. Taken after rebasing on #160, with the DatagramSocket spec fix that drops `old()` from the `closed(this)` preconditions. **1. Verification tab.** **Show in state machine** at the top of each state error, the badge on the tab, and the CodeLens in the editor (`State Refinement Error | Show in state machine`, cut off at the editor edge here). <img width="900" alt="Verification tab with Show in state machine buttons, tab badge and CodeLens" src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/159/1-verification.png?v=3" /> **2. Opening the State Machine tab** shows the first error. **3. The next error.** <img width="560" alt="First state error, 1 of 3" src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/159/2-first.png?v=3" /> <img width="560" alt="Second state error, 2 of 3" src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/159/3-next.png?v=3" /> **4. After visiting Context and coming back,** the same error is still shown. <img width="560" alt="State Machine tab after coming back, still 2 of 3" src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/159/4-back.png?v=3" /> **5. View error** returns to the `bind` error in the Verification tab and outlines it. <img width="560" alt="Verification tab with the bind error outlined" src="https://raw.githubusercontent.com/liquid-java/vscode-liquidjava/pr-screenshots/159/5-view-error.png?v=3" /> ## Tests Rebased on main after #160 (verifier 0.0.36, liquidjava-fsm 0.2.0, Spoon 11.5.0): - `npm run lint` and `npm run test:typecheck`: clean. - `npm run test:unit`: 89 passed. The new tests are in: - `state-errors.spec.ts`: errors of the current file in source order, re-finding after verification; - `fsm.spec.ts`: stepper, badge, an error from another file, the focus toggle in the legend; - `script.spec.ts`: opening on the first error, the badge counting only the current file, tab memory, stepping, cursor-following, View error, opening from the editor, a new file, no re-render without changes, the button at the top of the error. - `npm test` (VS Code): passing, including the state-errors integration test, which checks the CodeLens and the message it sends to the webview. - Server `mvn test` and the local smoke test: passed. Follow-ups stacked on this PR: #161 (errors the verifier cannot mark on the diagram) and #162 (tab order). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Closes #117.
When the State Machine view is opened from a state refinement error, it marks the rejected call on the full diagram. There are two sets of states:
The view marks:
Red and green have a faint fill and yellow is outline only, so a large machine stays calm.
The full diagram is always shown. Focus mode dims what does not help with the error:
getOption / receive / send / …onlyreceivestays bright.An arrow's path is dimmed only when all of its names are. "Show all" and "Focus on error" switch the dimming off and on and keep pan and zoom. The label text is identical in both modes, so the layout does not move.
A one-line legend shows only the marks that are present: "✕ Call rejected", "✓ Call allowed" and "Allowed, but not reachable here". In light themes the dashed outline uses a darker warning colour.
One summary line sits above the diagram, e.g. "
socket.receive()is rejected whensocketis in stateclosed· allowed in statebound".Edge cases
main.Data
possibleStates(Add the receiver's possible states to the error context liquidjava-fsm#11). With an older server, it falls back todefiniteFoundStateand thenactualStates.expectedStates.liquidjava-fsmto 0.1.5.Screenshots
These are real verifier output in headless VS Code.
UDP chat client. The study example
E_OSS_A1_22_UdpChatClient:receiveafter anifthat may close the socket. In focus mode the following stay bright:receive;closeandconnectout ofbound;closed.The accessors stay bright because the DatagramSocket spec writes
from = "closed(this) && connected(old(this))", which is drawn as an arrow fromclosedtoconnected. Thatold(...)in afromis a spec error, not an extension issue.Whole UDP machine: focus in dark and light, and Show all
DefaultMutableTreeNode (the issue's example).
getFirstChild()afterremoveAllChildren():childrenAllowedis invalid;maybeHasChildrenis accepted;add, the way there, stays bright;removeAllChildrenis dimmed.Dimmed unrelated state (simplified demo machine, not a real class)
Tests
Run against liquidjava-fsm 0.1.5 and verifier 0.0.35 from Maven Central:
npm run lintandnpm run test:typecheck: clean.npm run test:unit: 75 passed in 7 files.npm test(VS Code): 8 + 1 passing.mvn test: 24 passing.The new tests cover:
receivedoes not matchreceiveAll);Independently reviewed twice; all findings were fixed.
Known limits
main.🤖 Generated with Claude Code