Select an endpoint in the collection you clicked it in - #85
Merged
Conversation
Two collections describing the same API — staging and production — give every loaded endpoint the same id. That is not an accident: a loaded id is `endpointKey`, `"GET /users"`, and it carries no section because it is the identity a saved body and a refresh have to agree on. Putting the section in it would orphan every overlay entry on disk. Selection was keyed on that id alone, so all three of these were the same bug: both rows highlighted, `findRequest` answered with whichever collection sorted first regardless of which you clicked, and the second one could not be opened at all — the click set an id the store already held, so nothing changed and the row was inert. So the selection carries `selectedSectionId` alongside the id, and the sidebar's highlight compares both. `findRequest` takes the section as a *preference* rather than a filter: a history entry recorded before this existed names no section, and answering nothing for it would lose the request it points at, so the search still falls back to the first match. The regression test asserts the highlight count as well as the resolution. Without it the test passed against the broken build — the base-URL chip is driven by `selected`, which the store fix alone repairs, and the duplicated highlight needs its own assertion to be caught. Reverting `isSelected` now fails it with "Expected: 1, Received: 2". Response history is still bucketed by request id, so staging and production share one history for the same endpoint. Same root cause, not fixed here: re-keying it would orphan entries already written, and that wants its own change with a fallback rather than a silent loss.
Merged
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
1 participant
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.
Two collections describing the same API — staging and production — give every loaded endpoint the same id. That isn't an accident: a loaded id is
endpointKey,"GET /users", and it carries no section because it's the identity a saved body and a refresh have to agree on. Putting the section into it would orphan every overlay entry on disk.Selection was keyed on that id alone, which made three symptoms of one bug:
findRequestreturned whichever collection sorted first, whatever you clicked.Fix
Selection carries
selectedSectionIdalongside the id, and the sidebar's highlight compares both.findRequesttakes the section as a preference, not a filter: a history entry recorded before this existed names no section, and answering nothing for it would lose the request it points at — so the search still falls back to the first match, exactly as it did.Every site that writes a selection now sets both, including the removal paths (deleting a collection clears the selection by section rather than by an id the collection next door may also hold).
On the test
It asserts the highlight count as well as the resolution, and that mattered: the first version passed against the broken build. The base-URL chip is driven by
selected, which the store fix alone repairs — the duplicated highlight needed its own assertion. RevertingisSelectednow fails it withExpected: 1, Received: 2.Known, not fixed here
Response history is still bucketed by request id, so the same endpoint in staging and production shares one history — a production response can appear under staging. Same root cause. Re-keying orphans entries already on disk, so it wants its own change that records the section going forward and falls back for older entries, rather than a silent loss.
Testing
pnpm check(0 errors),pnpm test:e2e(323 passed, 1 new).