Skip to content

fix: deduplicate culprit frames - #16

Merged
GabrielBBaldez merged 1 commit into
stacktale:mainfrom
janithcd:fix/issue-15-duplicate-culprit-frame
Aug 15, 2026
Merged

fix: deduplicate culprit frames#16
GabrielBBaldez merged 1 commit into
stacktale:mainfrom
janithcd:fix/issue-15-duplicate-culprit-frame

Conversation

@janithcd

@janithcd janithcd commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • deduplicate the culprit location in text and st-json/1 frame lists
  • retain the marked culprit as the first navigable frame
  • preserve distinct frames when the culprit appears further down the stack
  • add regression coverage for format parity and non-top culprits

Root cause

Both parser paths add the explicit culprit and later add the same source location from the stack. The entries can have different marker text, so location identity must be determined using file and line.

Impact

Each culprit source location now appears once in the navigable frame list, preventing duplicate entries that open the same file and line.

Testing

  • npm test — 11 tests passed
  • git diff --check

Closes #15

@janithcd
janithcd marked this pull request as ready for review August 13, 2026 16:07

@GabrielBBaldez GabrielBBaldez left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked the part the issue flagged as the trap — that this stays a dedup and doesn't quietly become a reorder. Same report, culprit deliberately not at the top of the stack, before and after:

main       frames=4    [0] ServiceB.java:22   [1] ServiceA.java:11   [2] ServiceB.java:22   [3] ServiceC.java:33
this PR    frames=3    [0] ServiceB.java:22   [1] ServiceA.java:11   [2] ServiceC.java:33

Only the duplicate leaves. The culprit already sat at index 0 before this change, so hoisting isn't something the PR introduces — the surrounding order is untouched, which is what I wanted to be sure of before taking it.

The st-json/1 path returns the identical list for the equivalent report, so the two formats stay in agreement on a case neither had covered.

Comparing on file/line is the detail that makes it work: the culprit carries ← YOUR CODE and the stack copy doesn't, so a comparison on text would have matched nothing and left the bug in place behind a passing test.

Tests: 11/11 here, 7/11 against main. The four that fail there are the two new ones plus the two existing frame-count assertions the change legitimately moves.

Thanks for taking the format-parity assertion seriously rather than testing one path and assuming the other followed — the two mappings are independent code, and that test is what will catch them drifting apart.

@GabrielBBaldez
GabrielBBaldez merged commit 69ed6e7 into stacktale:main Aug 15, 2026
1 check passed
@janithcd
janithcd deleted the fix/issue-15-duplicate-culprit-frame branch August 15, 2026 04:27
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.

The culprit frame is listed twice in frames[]

2 participants