fix: deduplicate culprit frames - #16
Conversation
GabrielBBaldez
left a comment
There was a problem hiding this comment.
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.
Summary
st-json/1frame listsRoot 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
fileandline.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 passedgit diff --checkCloses #15