@BrunoQuaresma What do you think of this?

typeUseAgentLogsOptions=Readonly<{workspaceId:string;agentId:string;agentLifeCycleState:WorkspaceAgentLifecycle;enabled?:boolean;}>;exportfunctionuseAgentLogs(options:UseAgentLogsOptions,):readonlyWorkspaceAgentLog[]|undefined{const{ workspaceId, agentId, agentLifeCycleState, enabled=true}=options;constqueryClient=useQueryClient();constqueryOptions=agentLogs(workspaceId,agentId);const{ data}=useQuery({    ...queryOptions,    enabled,select:(logs)=>{return{        logs,lastLogId:logs.at(-1)?.id??0,};},});constsocketRef=useRef<WebSocket|null>(null);constlastInitializedAgentIdRef=useRef<string|null>(null);constaddLogs=useEffectEvent((newLogs:WorkspaceAgentLog[])=>{queryClient.setQueryData(queryOptions.queryKey,(oldLogs:WorkspaceAgentLog[]=[])=>[...oldLogs, ...newLogs],);});useEffect(()=>{constisSameAgentId=agentId===lastInitializedAgentIdRef.current;if(!isSameAgentId){socketRef.current?.close();}constcannotCreateSocket=agentLifeCycleState!=="starting"||data===undefined;if(cannotCreateSocket){return;}constsocket=watchWorkspaceAgentLogs(agentId,{after:data.lastLogId,onMessage:(newLogs)=>{// Prevent new logs getting added when a connection is not openif(socket.readyState===WebSocket.OPEN){addLogs(newLogs);;}},onError:(error)=>{// Might be able to put more precise error handling here?console.error(error);},});socketRef.current=socket;lastInitializedAgentIdRef.current=agentId;},[addLogs,agentId,agentLifeCycleState,data]);// The above effect is likely going to run a lot because we don't know when or// how agentLifeCycleState will change over time (it's a union of nine// values). The only way to ensure that we only close when we unmount is by// putting the logic into a separate effect with an empty dependency arrayuseEffect(()=>{constcloseSocketOnUnmount=()=>socketRef.current?.close();returncloseSocketOnUnmount;},[]);returndata?.logs;}

@BrunoQuaresma Realized one other thing: if the query for the agent logs hook is only able to run once, is it a problem if the query doesn't come back in the starting state at first?

I don't know enough about lifecycle states, and I don't know if there's a flow chart for how the states can transition into each other anywhere

@BrunoQuaresma Realized one other thing: if the query for the agent logs hook is only able to run once, is it a problem if the query doesn't come back in the starting state at first?

Do you have a use case that could contextualize this better?

Do you have a use case that could contextualize this better?
@BrunoQuaresma To be honest, I'm not sure – I was kind of hoping you would know

Looking at the type definition forWorkspaceAgentLifecycle, I see that there's aready state that sees like it could be a good candidate for the log functionality. But I don't know if that's actually true, or if there's some nuance that I'm missing. I would assume that from the names, a workspace transitions fromstarting toready

My main worry was, if a workspace is already in theready state, is it okay to skip generating logs for it? Or is it impossible for that to happen? The current logic only makes logs if we're specifically starting up

@Parkreiner I think I maybe answered this question here#13466 (comment)

@Parkreiner I had to roll back to the previoususeAgentLogs implementation because it was causing a loop since the data was in the dependencies list. I also removed the select option to get the last agent log ID because it updates on every data change keeping it unstable.

@Parkreiner I had to roll back to the previoususeAgentLogs implementation because it was causing a loop since the data was in the dependencies list. I also removed the select option to get the last agent log ID because it updates on every data change keeping it unstable.

@BrunoQuaresma Ah, right – forgot that we are mutating the cache, so the data is potentially going to be changing a lot