Companion - Googledrive, starts uploading then stops

ckcabs · May 28, 2025, 2:59pm

Hi everyone,

We’re using Uppy with Companion (in Docker) to support uploads from Google Drive, Dropbox, and OneDrive. Everything works fine for local uploads, but we’re seeing a consistent issue with Google Drive uploads.

The flow starts as expected — the Google auth succeeds, and the file begins uploading. However, shortly after (~5% progress), the logs stop generating and the Uppy UI just spins. No error message appears, and the file never completes.

From Companion’s debug logs, we can see:


companion: 2025-05-28T14:41:44.730Z [debug] 02a549d9 uploader.socket.wait socket connection received
companion: 2025-05-28T14:41:44.730Z [debug] null Socket connection received. Starting remote download/upload.
companion: 2025-05-28T14:41:44.937Z [debug] 02a549d9 uploader.total.progress 0 1299457 0.00%
companion: 2025-05-28T14:41:45.115Z [debug] 02a549d9 cleanup
companion: 2025-05-28T14:41:46.017Z [debug] null Instantiating uploader.
companion: 2025-05-28T14:41:46.017Z [debug] null Waiting for socket connection before beginning remote download/upload.
companion: 2025-05-28T14:41:46.017Z [debug] 1f721a5f uploader.socket.wait waiting for socket connection
::ffff:172.18.0.5 - - [28/May/2025:14:41:46 +0000] "POST /drive/get/1YUlyU3zgebumZoCEXyPhzEWNSwrVNhHr HTTP/1.1" 200 48 "https://support-1.nalytics.net/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36"
companion: 2025-05-28T14:41:46.072Z [info] socket.connect connection received from 1f721a5f-cb2e-46af-86e2-04f48747cd5d
companion: 2025-05-28T14:41:46.072Z [debug] 1f721a5f uploader.socket.wait socket connection received
companion: 2025-05-28T14:41:46.072Z [debug] null Socket connection received. Starting remote download/upload.
companion: 2025-05-28T14:41:46.310Z [debug] 1f721a5f uploader.total.progress 0 998673 0.00%
companion: 2025-05-28T14:41:46.327Z [debug] 1f721a5f cleanup

And then nothing further — no failure, no post-finish, no timeout.

Our Companion container is set up with:

All required Google config vars (including COMPANION_GOOGLE_KEY and COMPANION_GOOGLE_SECRET)
RemoteSources configured with 'GoogleDrive'
Valid redirect URI: https://support-1.nalytics.net/companion/google/callback

Has anyone run into similar behavior — where Google Drive uploads hang mid-transfer? Any tips on debugging or resolving this would be hugely appreciated.

Thanks in advance!

Merlijn · May 29, 2025, 8:14am

Hi, you don’t experience any problems with Dropbox/Onedrive? Could you try @uppy/google-drive instead of remote-sources as a sanity check?

ckcabs · May 30, 2025, 9:45am

Hi Merlin,

thank you for your message.
i tried with onedrive and that worked fine

using
.use(RemoteSources, {
sources: [‘Dropbox’,‘OneDrive’, ‘GoogleDrive’, ‘Url’],
companionUrl: ResourceSets.uppyGetURLRoot() + ‘/companion’
}
not sure how to configure
@uppy/google-drive

any ideas why is stopping after successfully uploading 180mb of files via googledrive?

ckcabs · May 30, 2025, 10:29am

could it be related to the google app being unnverified when might withstrict the amount of data being accessed??

Merlijn · June 2, 2025, 8:55am

Hi, for google drive you do need to pass an extensive security check by Google. If you do not plan on doing that I recommend taking a look at Google Drive Picker | Uppy

ckcabs · June 12, 2025, 3:15pm

Subject: Clarification on Google OAuth Scope Issue with Companion

Hi Merlijn,

I wanted to run something past you to check if this aligns with your understanding.

I recently went through the verification process for Google Drive access. Initially, I requested the drive.readonly scope, but Google responded with the following:

We won’t be able to approve restricted Drive APIs for your application if your request does not meet the minimum scope requirement under the Workspace API user data and developer policy… The drive.file scope allows the user to create Drive files and select/modify any file they wish to share, offering more user control and security. UI preferences or client library limitations are not valid exceptions.

Based on this, I added drive.file instead and resubmitted. However, I was still seeing the “unverified app” screen.

To troubleshoot, I created a clean test project using only the drive.file scope — same result.

When clicking “Authenticate with Google,” I inspected the OAuth URL and found that it still includes the drive.readonly scope, despite having updated the Companion configuration to only request drive.file:

https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?client_id=10dfds52268953716-63jmt51u65mjf32hochnh8amghlboete.apps.googleusercontent.com&response_type=code&redirect_uri=https%3A%2F%2Fxxxx.xxx.net%2Fcompanion%2Fdrive%2Fredirect&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.readonly&state=72345bb8634a129d07a31a398e264ba1292de689&access_type=offline&prompt=consent&service=lso&o2v=2&flowName=GeneralOAuthFlow)

This leads me to believe that Companion is defaulting to drive.readonly internally, unless explicitly overridden.

I’ve now gone back to Google again and requested approval for drive.readonly, as it seems to be required for Companion to function as expected out of the box.

Does that sound right to you? Have you come across this default behaviour before where Companion insists on drive.readonly unless forcibly configured otherwise?

Appreciate any insight you might have.

Best regards,
Chris

Merlijn · June 16, 2025, 8:32am

Companion uses drive.readonly indeed as that’s the only thing that works. Note that you will remain unverified until you completely went through the Google approval process and as I mentioned that can take months and a third-party security audit. In the end, you do get good UX for your users. If you do not want to go through that process, take a look at Google Drive Picker | Uppy

ckcabs · June 18, 2025, 7:40am

Hi Merlijn,

We received a response from Google, but unfortunately, it wasn’t helpful — their recommendation was simply to use the Google Drive Picker.

As a result, I’ve begun integrating the GoogleDrivePicker plugin into our production document management application, using Uppy v4.17.0. This replaces our previous use of RemoteSources to allow users to import files directly from Google Drive.

Our configuration is as follows:

.use(GoogleDrivePicker, {
  clientId: '...',
  apiKey: '...',
  appId: '...',
})

The picker UI appears and allows file selection without issue. However, when initiating the upload, it consistently fails with the following error in the console:

Cannot read properties of undefined (reading 'replace')
at uploadRemoteFile

This occurs during the uppy.upload() step and points to:

file.remote.url.replace(...)

Upon further inspection, we found that file.remote is undefined for files selected via GoogleDrivePicker, which seems to contradict Uppy’s expected behavior for remote file uploads.

Observations

lastModifiedDate is also undefined for the selected files.
No upload request is made to tusd — the failure occurs before any network call is triggered.
The critical metadata (file.remote) used in Uppy’s remote upload lifecycle is not set.
Other plugins like Dropbox and OneDrive work as expected via Companion.

After reviewing Issue #3473 and running additional tests, it appears that:

The GoogleDrivePicker plugin currently only supports metadata selection and does not integrate with the upload lifecycle (e.g., no file.remote.url or file stream is available for upload).

Are you able to advise?

Is this limitation expected behavior for the GoogleDrivePicker plugin?

Appreciate any guidance you can provide.

Best regards,

Chris

mifi · June 18, 2025, 7:37pm

Hi. Not sure I follow here. I can’t see the full stack trace, but looking inside uploadRemoteFile, I cannot find any file.remote.url.replace(...). the closest I can find is url.replace(...) inside stripSlash(...) which gets called from here:

github.com/transloadit/uppy

packages/%40uppy/companion-client/src/RequestClient.ts

a83b66c86


      
          }
          
          setCompanionHeaders(headers: Record<string, string>): void {
            this.#companionHeaders = headers
          }
          
          private [Symbol.for('uppy test: getCompanionHeaders')](): CompanionHeaders {
            return this.#companionHeaders
          }
          
          get hostname(): string {
            const { companion } = this.uppy.getState()
            const host = this.opts.companionUrl
            return stripSlash(companion && companion[host] ? companion[host] : host)
          }
          
          async headers(emptyBody = false): Promise<Record<string, string>> {
            const defaultHeaders = {
              Accept: 'application/json',
              ...(emptyBody ? undefined : (
                {

According to typescript, companion && companion[host] ? companion[host] : host will always be a string, never undefined, so I’m not sure how you can get this error. Maybe it’s because our code is not yet completely type safe (Fix TypeScript sins · Issue #5336 · transloadit/uppy · GitHub). Do you have a running example to reproduce this error, or code that can reproduce it using companionUrl https://api2.transloadit.com/companion?

mifi · June 18, 2025, 7:40pm

Which uploader are you using? Is it possible that the endpoint argument is undefined? Blaming uppy/packages/@uppy/aws-s3/src/index.ts at a83b66c86631cd7cfd9103b112c3c675c4a03a59 · transloadit/uppy · GitHub

Topic		Replies	Views
Files does not upload from Uppy using companion Uppy	2	353	January 10, 2024
Uppy - Companion - Google drive - Socket- Emitter never fires Uppy	1	1086	July 28, 2020
Companions Cors Errors Uppy	1	376	September 11, 2023
Companion not starting on live Uppy	0	373	August 10, 2023
Companion GoogleDrive to XHRUpload Uppy	2	2222	September 27, 2019

Companion - Googledrive, starts uploading then stops

Observations

Are you able to advise?

Related topics