Google Meet Add-on stopped initializing after trying to add CoDoingClient (even after reverting)

Google Workspace Developers Q&A
, , ,
1

I built a Google Meet add-on that loads an Angular web app inside the Meet side panel. The app initializes the Meet Add-on SDK, creates a session, gets meeting info, and then lets a bot connect via WebRTC to capture meeting audio streams.

This setup was working correctly before.

Architecture

  • Angular frontend loaded in the Meet side panel

  • Meet Add-on SDK (meet.addons.js)

  • WebRTC connection to Meet Media API

  • Cloud Run proxy exchanging SDP offer/answer

  • Audio mixed with Web Audio API and recorded using MediaRecorder

What changed

I started experimenting with CoDoingClient from the Meet Add-on SDK. To support that, I added this field in the deployment config:

"supportsCollaboration": true

After adding that, the add-on stopped initializing in Meet.

I then:

  • Removed "supportsCollaboration": true

  • Reverted deployment.json to the previous working version

  • Reverted the web app to the last known working revision

  • Deleted the HTTP deployment

  • Created a new deployment

  • Republished it in the Workspace Marketplace store listing

Even this did not help, and the side panel still says that the add-on couldn’t start (no logs in console). It is not published publicly but as an internal Workspace app.

Current problem

When launched inside Meet:

  • My Angular logs never appear

But if I open the same sidePanelUrl directly in the browser, the app loads and works normally, and does show logs in the console.

Deployment config (current)

{
  "addOns": {
    "common": {
      "name": "Meet Add-on",
      "logoUrl": "..."
    },
    "meet": {
      "web": {
        "supportsScreenSharing": true,
        "addOnOrigins": ["https://my-cloud-run-url"],
        "sidePanelUrl": "https://my-cloud-run-url/some-path/meet-addon"
      }
    }
  }
}

Questions

  1. Could enabling supportsCollaborationonce cause a persistent state/caching issue in Meet deployments?

  2. Does Meet cache add-on deployments or manifests aggressively?

  3. Is there a way to debug what happens before the add-on actually boots inside Meet?

Any insight from people who have worked with the Meet Add-on SDK would be really helpful.

Thanks,

2

Update:

Everything appears to be working now. The issue turned out to be related to caching on the Cloud Run service, where the application was deployed.

To verify this, I deployed the same application to a new Cloud Run service, and the add-on initialized correctly in Google Meet. I had previously tried several other approaches, including switching projects and organizations and creating a new Workspace Marketplace app, but none of those resolved the issue.

In the end, deploying to a new Cloud Run service fixed it. I will now try deleting the existing service builds to see if that resolves the caching issue on the original service as well.

Thanks.