Giters

MatrixAI / js-rpc

Stream-based JSON RPC for JavaScript/TypeScript Applications

Home Page:https://polykey.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Remove timeout grace timer for `RPC` system

tegefaulkes opened this issue · comments

commented

Specification

In the RPC system, specifically the server side. The handler can be cancelled or timed out from the ctx: ContextTimed. This will result in a signal that SHOULD cause the handler to end immediately. It is possible for the handler to ignore this however.

Currently there is some logic what will wait a certain delay after cancellation and then force close the stream the handler was handling. This logic needs to be removed.

The reasoning is, we should allow for an arbitrary delay in handling a signal. But also, programmatic problems such as deadlocks should not be silently handled by a fail safe such as this. It should be found and dealt with during testing.

Additional context

Tasks

  1. Remove grace timeout timer logic from the RPC system.
  2. Remove any tests that test this and update ones that depend on it.
commented

RPC issues should all go to js-rpc now. So I'm moving there.

commented
  1. The AbortController and Timer logic seems to be implemented for each handler and is used to abort the process or refresh the timeout. The grace timeout mechanism looks to be enforced through a separate Timer (graceTimer).
  2. To remove this grace timeout, remove or comment out the code related with the graceTimer and its event listener (handleAbort).
  3. Remove jests related to same.
  • Remove graceTimer
  • Remove event listener
  • Remove jests
commented

Yes grace timer removal is because of these reasons:

  1. Timeouts are advisory always. This is because JS is a cooperative concurrency system not a pre-emptive concurrency system. This advisory cancellation is fundamental.
  2. There is an option for the decorator called lazy. If it is false, the promise rejects but that doesn't mean the underlying operation is finished. It's just an early rejection.
  3. In all cases where IO is involved, early rejection is incorrect. Therefore all uses of times cancellability of RPC calls must have lazy set to true.
  4. We can enforce this in the RPC handlers and callers or... Which would be easier than expecting the user to always set it up correctly. However I'm not sure about ergonomics. Provide some examples of tradeoffs here @addievo
commented

Also remember to tick off the tasks in the OP and not just create new tasks. Always update the OP with tasks.