Next camp remove useChatEngine

[zanesq]

Summary

Bring over missing power saver blocker and other functionality from useChatEngine and remove useChatEngine and related unused code

Bonus: Added missing click to view functionality to notification

Follow up for #5706

[DOsinga]

happy to get this finally in, but I do think we should pay attention not to sneak back in the sins of old, like storing messages, extra useEffects etc

[DOsinga]

what is this?

[DOsinga]

we just painstakingly deleted this again, why are we bringing this back? redeclaring this as JsonValue over the unknown that the api generates, what does that get us? we could keep:

type NotificationEvent = Extract<MessageEvent, { type: 'Notification' }>;

but even there I am not sure we need it

[zanesq]

If I remove this and just use the base api type it has these typescript issues

src/components/ToolCallWithResponse.tsx:166:12 - error TS2339: Property 'data' does not exist on type '{}'.

166     params.data &&
               ~~~~

src/components/ToolCallWithResponse.tsx:167:19 - error TS2339: Property 'data' does not exist on type '{}'.

167     typeof params.data === 'object' &&
                      ~~~~

src/components/ToolCallWithResponse.tsx:168:24 - error TS2339: Property 'data' does not exist on type '{}'.

168     'output' in params.data &&
                           ~~~~

src/components/ToolCallWithResponse.tsx:169:24 - error TS2339: Property 'data' does not exist on type '{}'.

169     'stream' in params.data
                           ~~~~

src/components/ToolCallWithResponse.tsx:171:23 - error TS2339: Property 'data' does not exist on type '{}'.

171     return `[${params.data.stream}] ${params.data.output}`;
                          ~~~~

src/components/ToolCallWithResponse.tsx:171:46 - error TS2339: Property 'data' does not exist on type '{}'.

171     return `[${params.data.stream}] ${params.data.output}`;
                                                 ~~~~

src/components/ToolCallWithResponse.tsx:174:17 - error TS18046: 'params' is of type 'unknown'.

174   return typeof params.data === 'string' ? params.data : JSON.stringify(params.data);
                    ~~~~~~

src/components/ToolCallWithResponse.tsx:174:44 - error TS18046: 'params' is of type 'unknown'.

174   return typeof params.data === 'string' ? params.data : JSON.stringify(params.data);
                                               ~~~~~~

src/components/ToolCallWithResponse.tsx:174:73 - error TS18046: 'params' is of type 'unknown'.

174   return typeof params.data === 'string' ? params.data : JSON.stringify(params.data);
                                                                            ~~~~~~


Found 9 errors in the same file, starting at: src/components/ToolCallWithResponse.tsx:166

The auto-generated API types from the OpenAPI spec define the Notification event's message as:

{
  message: {
    [key: string]: unknown;
  };
  request_id: string;
  type: 'Notification';
}

TypeScript sees params as unknown, so it can't access properties like params.data so we need to we need to refine the type to match the actual MCP notification structure.

The alternative is adding a bunch of type guards wherever this is used and that is way more messy.

Not sure why you think we don't need this, we want to define the type and make typescript happy. Can come back to it later when we refine the backend api types

[DOsinga]

that is not defining the type it is changing it into anything goes. the code we're using it sometimes does the right thing like:

const notificationToProgress = (notification: NotificationEvent): Progress =>
  notification.message.params as unknown as Progress;

that seems much better

[zanesq]

ah I understand what you are saying now :) ok updated in the parent branch since this is merged

[DOsinga]

we shouldn't need a cast here

[zanesq]

We still need as NotificationEvent when handling the event because TypeScript's discriminated union doesn't automatically narrow the type in the switch case - it still sees the broader MessageEvent type.

[DOsinga]

doesn't this immediately run when powerSaveTimeoutId gets set and therefore immediately clears the timer and the power saver blocker?

[DOsinga]

this power save blocker stuff breaks multi chat. is the idea that we keep the computer awake but for at most 15 minutes? does that really help people?

if we want to keep this around and actually make it work, I think this needs to move to a separate thing where we keep track of all the sessions and all the time outs.

I'd be happy to ship without this for now too though

[DOsinga]

if a comment starts lying, delete it. also though, we should just remove that from progressivemessagelist