fix: preserve recentlyHandledRequestsCache across watchdog reset to p…

[dearlordylord]

…revent handled request refetch

• _reset() in request_provider.ts cleared recentlyHandledRequestsCache on watchdog timeout (5min inactivity)
• This cache is the only local guard preventing _ensureHeadIsNonEmpty from re-adding handled requests to queueHeadIds when server listHead() returns stale data
• After clearing, handled requests get re-dequeued and re-processed silently (data duplication via double pushData())

Why removing the clear is safe

recentlyHandledRequestsCache is only populated in two places, both after server confirmation:

1. markRequestHandled()
2. fetchNextRequest()

No code path adds a pending/unhandled request to this cache. Preserving it across reset cannot cause a stuck queue because every entry genuinely represents a handled request.

Additionally fetchNextRequest has a secondary server-side guard: even if a request somehow passes the cache filter, getRequest() checks request.handledAt and returns null. But relying solely on this is wasteful (unnecessary server roundtrips)

The cache is LRU-bounded at 1000 entries, no memory concern from preserving it.

[janbuchar]

Hi @dearlordylord, I did not examine this carefully yet. Do I understand it right that the race condition you describe happens because after resetting the queue here?

[dearlordylord]

Hi @dearlordylord, I did not examine this carefully yet. Do I understand it right that the race condition you describe happens because after resetting the queue here?

Yes exactly. Specifically: it's not the whole _reset() that's the problem, it's the recentlyHandledRequestsCache.clear() inside it. The other clears (queueHeadIds, counters, requestCache) are fine and serve the unsticking purpose.