Skip to content

Keep each collection's response history to itself - #87

Merged
MathiasWP merged 1 commit into
mainfrom
fiber-collision-probes
Aug 24, 2026
Merged

Keep each collection's response history to itself#87
MathiasWP merged 1 commit into
mainfrom
fiber-collision-probes

Conversation

@MathiasWP

Copy link
Copy Markdown
Owner

Hunting the same shape as the selection bug — an identifier assumed unique that isn't — by writing probes that assert the correct behaviour and letting the failures name the bugs.

Five probes over two collections describing one API. Two failed, and both were the same bug.

Found: history is shared between collections

Bucketed by request id alone, and a loaded endpoint's id is METHOD /path in every collection describing that API. So:

  • Sending in staging, then opening production, showed staging's response under production.
  • Both sends landed in one bucket, so clearing one cleared the other — including from disk, since clear_request matched on request_id.

Fix

Most of it was already there: the database has stored section_id since the column was added and simply never returned it. Selecting it onto HistoryRecord is enough for the window to tell the two apart. clear_request takes an optional section; unscoped still means everywhere, which is what scratch needs.

Old entries match any collection rather than vanishing — nothing knows where they came from, and dropping them would read as history lost. A scoped clear takes them too: they're the same request's older entries, and leaving them behind would look like the clear half-worked.

Passed, and kept

  • Editing a body in one collection doesn't change the other (overlay is section-scoped).
  • Forgetting an orphaned endpoint in one leaves the other's.
  • Opening an endpoint asks for its own collection's schema.

They cost nothing and they're what would notice if any of those stopped being section-scoped.

On the probes themselves

Two early drafts passed by taking an if around a context-menu item that doesn't exist for loaded rows — a test that asserts nothing when its branch isn't taken is worse than no test. Both were rewritten to be unconditional, and there are no skips.

Verified the way the last one had to be: reverting the filter fails the probe.

Testing

cargo fmt --check, cargo clippy --no-default-features --all-targets -- -D warnings, cargo test (137 passed), pnpm check (0 errors), pnpm test:e2e (328 passed, 5 new).

Hunting the same shape as the selection bug — an identifier assumed unique
that isn't — with probes that assert the correct behaviour and let the
failures name the bugs. Five written, two failed, and both were the same
one: history is bucketed by request id alone, and a loaded endpoint's id is
`METHOD /path` in every collection describing that API.

So staging and production shared one list. Opening either showed whichever
had been sent last, and clearing one deleted both — including from disk,
since `clear_request` matched on request_id.

The fix was mostly already there: the database has stored `section_id`
since the column was added, and simply never returned it. Selecting it and
putting it on `HistoryRecord` is enough for the window to tell the two
apart. `clear_request` takes an optional section, and unscoped still means
everywhere, which is what scratch needs.

Entries recorded before this match any collection rather than vanishing —
nothing knows where they came from, and dropping them would read as history
lost. A scoped clear takes those too: they are the same request's older
entries, and leaving them would look like the clear half-worked.

The three probes that passed are kept. They cost nothing to run and they
are the ones that would notice if overlay bodies, endpoint-forgetting or
schema lookups ever stopped being section-scoped. Two earlier drafts of
them passed by taking an `if` around a menu item that is not there for
loaded rows; a test that asserts nothing when its branch is not taken is
worse than no test, so both were rewritten to be unconditional.

Verified the way the last one had to be: reverting the filter fails the
probe.
@MathiasWP
MathiasWP merged commit a703582 into main Aug 24, 2026
4 checks passed
@MathiasWP
MathiasWP deleted the fiber-collision-probes branch August 24, 2026 15:47
@github-actions github-actions Bot mentioned this pull request Aug 24, 2026
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.

1 participant