The pubsub usage for workspace metadata updates, where the UpdateWorkspaceAgentMetadata also calls pubsub.Publish can be quite expensive in deployments with a larger workspace/workspace agent count.

IIUC the Publish call leads to a DB wide lock on the message queue portion within PG. End users can try to reduce the impact of these calls by setting higher metadata update intervals for each agent metadata in a template, but in reality the end user facing functionality doesn't really need to be achieved via pubsub imo.

ATM, the only subscriber for these events is the Workspace UI page, where a user is viewing a single workspace. I would assume that most of the time people don't leave the workspace page open after starting a workspace and connecting via some IDE. This assumption means that we're sending a lot of publish events when there's no subscriber that wants to receive them. This still puts some amount of processing load on the DB even though there's no one who wants the data. On top of that, it's easy for end users to set (or not set, and get the default) low metadata update intervals, and it's not immediately clear to them that the lowest interval in the whole template is the frequency on which that agent will send UpdateWorkspaceAgentMetdata/Publish calls to the DB.

I am also assuming that having the UI show to-the-second up to dateThis is doubly true for workspaces that are used by AI related tasks.

Therefore, of someone is really viewing their workspace UI page it seems reasonable to simply poll the database for that workspaces agent metadata.

NOTE: I've built and tested this within a workspace using develop.sh and verified the polling works. We likely still want to add a frontend test and potentially change the interval and/or retry behaviour as well as the message in the FE when the metadata cannot be retrieved.

Also blink tasks helped with these changes.