Factoring out the Timeout Middleware from PK to js-rpc

[addievo]

Specification

Factor out the timeout middleware.

Tasks

• 1. Move timeout middleware into js-rpc.
• 2. Move the rpc request and response types to js-rpc. Replace the ClientRPCRequestParams as an extension of the default request and response types. You can create a more specific subtype when using extends here. This applies also to AgentRPCRequestParams and associated.
• 3. Timeout middleware must be applied to the agent service as well.

[CMCDragonkai]

I believe the timeoutMiddleware that is currently PK's src/client should actually be part the default middleware, since it is a core function of js-rpc.

https://github.com/MatrixAI/Polykey/blob/staging/src/client/timeoutMiddleware.ts

This should really be in js-rpc.

I think this (https://github.com/MatrixAI/Polykey/blob/staging/src/client/types.ts):

// Prevent overwriting the metadata type with `Omit<>`
type ClientRPCRequestParams<T extends Record<string, JSONValue> = ObjectEmpty> =
  {
    metadata?: {
      [Key: string]: JSONValue;
    } & Partial<{
      authorization: string;
      timeout: number;
    }>;
  } & Omit<T, 'metadata'>;

// Prevent overwriting the metadata type with `Omit<>`
type ClientRPCResponseResult<
  T extends Record<string, JSONValue> = ObjectEmpty,
> = {
  metadata?: {
    [Key: string]: JSONValue;
  } & Partial<{
    authorization: string;
    timeout: number;
  }>;
} & Omit<T, 'metadata'>;

This can be part of the js-rpc library as well. The only thing imposition here is simply the fact that js-rpc says we need to reserve the constraint property in the request and response messages.

[CMCDragonkai]

If you want to make it flexible it can be parameterised as the "reserved key".

[CMCDragonkai]

ATM the agent service is not using the timeout middleware at all, and it should be. So there needs to be a fix here too.

[CMCDragonkai]

You can work on this @addievo and start a PR here and a PR in Polykey, they should be kept in sync.

[CMCDragonkai]

Note that this is incorrect:

// Prevent overwriting the metadata type with `Omit<>`
type AgentRPCRequestParams<T extends Record<string, JSONValue> = ObjectEmpty> =
  {
    metadata?: {
      [Key: string]: JSONValue;
    } & Partial<{
      authorization: string;
      timeout: number;
    }>;
  } & Omit<T, 'metadata'>;

// Prevent overwriting the metadata type with `Omit<>`
type AgentRPCResponseResult<T extends Record<string, JSONValue> = ObjectEmpty> =
  {
    metadata?: {
      [Key: string]: JSONValue;
    } & Partial<{
      authorization: string;
      timeout: number;
    }>;
  } & Omit<T, 'metadata'>;

The authorization for agent service cannot happen, it's always a public service.

[CMCDragonkai]

This is part of #551, and we want to make sure this is ready by mid next week.

[addievo]

Alright, just imported ClientRPCRequestParams and ClientRPCResponseResult and exported them to use in middleware, thats it for js-rpc.

1. Copied over the timeoutMiddlewareClient and timeoutMiddlewareServer functions to js-rpc src/middleware
2. To be implemented in default middleware.

[CMCDragonkai]

They should not have the Client prefix anymore. It is generic now.

[CMCDragonkai]

If you want to make it flexible it can be parameterised as the "reserved key".

Remember this too.

[addievo]

Timeout middleware on chunk.params doesn't make much sense in rpc context as in PK we assumed all values to be a valid JSON, but in RPC they aren't, consequently, while the middleware is now working in rpc, many jests are failing due to the same. And therefore it would make more sense on chunk

[CMCDragonkai]

I don't know what you mean.

[tegefaulkes]

Allow users to extend or modify middleware while also keeping the default functionality. This is already a feature, middleware is provided by the user through the middlewareFactory parameter. You compose it with the default by using the utility functions.