test(portals): pin that a blocked refresh stops before the guard reset

The serialization test proved the second run was refused, but only through a
`sendIpcEvent` call count — the ordering was implied rather than stated. Assert
the recorded sequence directly instead: the refused call must add nothing at
all, leaving exactly one guard reset and one delete.

The distinction matters because the reset is what re-opens a host after the
failures that led here. A check placed after it would let a run that is not
allowed to proceed clear that evidence on the way out. Moving the in-flight
check (and its insertion) below the reset now fails this test.

Raised by Greptile on #1431.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
4grayandClaude Opus 5 committed 2026-08-13 09:23:55 +02:00
1 parent 5165300981
commit 3f7034a2f1
1 file changed
+10 -2
@@ -199,11 +199,19 @@ describe('XtreamRefreshFlowService', () => {
// The row's reporter honestly reports "not busy": it tracks its own id
// set and never saw the header action start. Only the flow can refuse
// this, and it must refuse before the guard reset — a second run would
// park an already-emptied catalog over the first run's snapshot.
// this, and it would park an already-emptied catalog over the first
// run's snapshot.
const observedBeforeSecondConfirm = [...order];
service.confirmAndRefresh(item, sourcesRow.reporter);
await Promise.resolve();
// Rejected before the connectivity-guard reset, not merely before the
// delete: the reset is what re-opens the host after the failures that
// led here, so a second one inside the first run's window would clear
// evidence on behalf of a run that is not allowed to proceed. The
// refused call must therefore add nothing at all.
expect(order).toEqual(observedBeforeSecondConfirm);
expect(order).toEqual([`ipc:${CONNECTIVITY_GUARD_RESET}`, 'delete']);
expect(sourcesRow.calls).toEqual([]);
expect(
databaseService.deleteXtreamPlaylistContent