`drive files download` vs `drive files get --params alt=media`: guide which to use; `download` returns 500 `backendError` on ordinary files

Open Beginner friendly
#727 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
62/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet

Research direction

Start by inspecting the help output for drive files download and the existing Drive recipes or documentation. Compare the documented download and files get --params '{"alt":"media"}' paths, then make the ordinary-file guidance explicit; done means users are directed to the working binary-download pattern and the long-running-operation scope is clear.

Written by the indexing model from the issue text.

Description

Problem

Two subcommands look like they do the same thing, but only one works for ordinary file downloads:

  • gws drive files downloadalways returns 500 Internal error encountered (backendError) on regular Drive files (My Drive WAV/JPG/JSON/PDF, etc.)
  • gws drive files get --params '{"alt":"media"}' → works correctly

The name download strongly suggests it's the right choice, especially for agents/LLMs generating calls from the schema. It isn't — drive.files.download is a long-running operation (POST) intended for a narrow set of cases (e.g. exporting Google Vids, large export operations). For arbitrary binary downloads the correct call is files.get with alt=media.

Reproduction

FID="<any regular Drive file ID>"

# Fails every time:
gws drive files download --params "{\"fileId\":\"$FID\",\"alt\":\"media\"}" -o out.bin
# → { "error": { "code": 500, "message": "Internal error encountered.", "reason": "backendError" } }

# Works every time:
gws drive files get --params "{\"fileId\":\"$FID\",\"alt\":\"media\"}" -o out.bin

Verified on `gws 0.22.5` (macOS, Apple Silicon). 3/3 failures vs 3/3 successes against the same file ID.

Why this hurts

Agents that write calls from the discovery schema gravitate to the one literally named `download`. The resulting 500 gives no hint that a different verb is the right answer; users spend a long time assuming Drive is down or the CLI is broken. (I sunk ~30 minutes before figuring it out.)

Suggestions (any one helps)

  1. Help text / docs — add a one-liner to `drive files download --help` and any relevant recipe: "For ordinary file content downloads use `drive files get --params '{"alt":"media"}'`; this command is for long-running operations only."
  2. Recipe — add `recipe-drive-download` (or similar) that shows the `files.get` + `alt=media` pattern with `-o` for binaries and stdout for text.
  3. Pre-flight warning — if `drive files download` is invoked against a file whose MIME type doesn't require the long-running path, emit a warning pointing at `files get`.

Happy to open a PR for (1) if that's the preferred shape.

Dominant language
Rust
Stars
31.1k
Forks
1.8k
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from googleworkspace/cli

All issues in googleworkspace/cli

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.