akiomik / akiomik/nosvelte

A refetch reuses the same rxReqId, so its REQ is silently dropped

Offen
#94 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
bug
Vorherrschende Sprache
TypeScript
Sterne
29
Forks
3
Ø Merge
3 Std. 5 Min.
Gemergte PRs (30 T.)
11

Beschreibung

`useReq()` creates its req once, when the hook is called
(`src/lib/stores/useReq.ts:37`), and builds one observable from it
(`:42`). Every fetch attempt then re-subscribes that same observable.

rx-nostr derives the wire subId as `` `${rxReqId}:${index}` `` where `index` is a
*per-subscription* counter that restarts at 0
(`rx-nostr/utils.ts:11-18`, `rx-nostr.ts:353-357`). A req object carries one
`rxReqId` for its whole life (`rx-req.ts:125`), so **every attempt sends the
identical subId**.

For a backward/oneshot req `use()` passes `overwrite: false`, and the connection
drops a REQ whose subId is already in flight
(`connection/connection.ts:181`):

```ts
if (!overwrite && this.subProxy.isOngoingOrQueued(subId)) return;
```

So a refetch that starts while the previous subscription is still open never
reaches the relay at all.

Verified on `main` (609f8ed) against the mock relay: a list hook received one
event, was refetched before EOSE, and the relay saw a single message for the
whole test —

```
WIRE: [["REQ","408976:0",{"kinds":[1]}]]
```

The refetch produced no REQ, no error, and no change in status. The query
resubscribes an operator chain that is fed by a subscription the relay is no
longer being asked to serve.

This is a different defect from #82, which is about the accumulator restarting
from its seed. Both fire on the same refetch, and #82's report notes the missing
second REQ as a symptom; this issue is the cause of that half.

## Interaction with a caller-supplied forward req

A forward req uses `overwrite: true`, so the duplicate is not dropped — the new
REQ replaces the old one on the wire while **both** RxJS chains keep filtering on
the same subId. Combined with #61 (the previous subscription is never torn down)
that means two live chains writing different accumulations to one cache key.

## Direction

Mint a fresh req — and therefore a fresh subId — per fetch attempt rather than
per hook call. Passing an explicit `rxReqId` to the factory is enough; all three
factories accept one (`rx-req.ts:164`, `:188`, `:204-207`).

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.