[passthrough] Google Drive Export action — query parameters not forwarded to API

[lucasygu]

Summary

The Google Drive "Export a File" action (conn_mod_def::GJ6RziZnVhE::KyuPyhkzQ1K3CQxYqa8IGA) requires mimeType as a query parameter, but the One CLI passthrough is not forwarding it to the Google API. Every export request fails with "The requested conversion is not supported" — which is Google's response when mimeType is missing entirely from the request.

Reproduction

# This should export a Google Doc as plain text
one --agent actions execute google-drive \
  "conn_mod_def::GJ6RziZnVhE::KyuPyhkzQ1K3CQxYqa8IGA" \
  "<connection-key>" \
  -d '{}' \
  --path-vars '{"fileId":"<valid-google-doc-id>"}' \
  --query-params '{"mimeType":"text/plain"}'

Expected: Returns the file content as plain text.

Actual:

{
  "error": {
    "code": 400,
    "message": "The requested conversion is not supported.",
    "errors": [{
      "message": "The requested conversion is not supported.",
      "domain": "global",
      "reason": "badRequest",
      "location": "convertTo",
      "locationType": "parameter"
    }]
  }
}

Tested variations — all fail with the same error

#	fileId in	mimeType in	Result
1	data body	data body	404 File not found: {{fileId}} (template literal not resolved)
2	pathVars	queryParams	400 conversion not supported
3	pathVars	data body	400 conversion not supported
4	pathVars	queryParams (URL-encoded text%2Fplain)	400 conversion not supported
5	pathVars	queryParams (application/pdf)	400 conversion not supported
6	via flow engine with queryParams	queryParams	400 conversion not supported

Every mimeType value fails identically. The error is consistent with mimeType never reaching the Google API.

Confirmed the file supports export

The same file, queried via the List Files action with fields=files(exportLinks), returns:

{
  "exportLinks": {
    "text/plain": "https://docs.google.com/feeds/download/documents/export/Export?id=...&exportFormat=txt",
    "text/html": "https://docs.google.com/feeds/download/documents/export/Export?id=...&exportFormat=html",
    "application/pdf": "https://docs.google.com/feeds/download/documents/export/Export?id=...&exportFormat=pdf"
  },
  "mimeType": "application/vnd.google-apps.document"
}

The file is a real Google Doc that supports all standard export formats. The issue is not with the file.

Other actions pass queryParams fine

Google Calendar's "List Events" action uses queryParams (timeMin, timeMax, singleEvents, orderBy) and they work correctly through the passthrough. So this may be specific to:

• The Google Drive export action specifically
• GET requests where the only meaningful parameters are query params (no request body)
• Or a mismatch in how this action's passthrough URL is constructed

API reference

Google Drive Export: GET https://www.googleapis.com/drive/v3/files/{fileId}/export?mimeType=text/plain

Action path template: /drive/v3/files/{{fileId}}/export

The mimeType is not in the path template — it must be appended as ?mimeType=... by the passthrough.

Impact

This blocks any workflow that needs to read Google Drive document contents — including RAG chatbots, document analysis, and content extraction flows. The "RAG Chatbot for Company Documents" flow (n8n workflow #10, 284K views) hits this on every file export attempt.

[moekatib]

Investigated this on the CLI side. The CLI correctly appends query params to the passthrough URL — e.g., https://api.withone.ai/v1/passthrough/drive/v3/files/{fileId}/export?mimeType=text%2Fplain.

The encoding is correct per URL spec (text%2Fplain is the standard encoding of text/plain in query strings). The issue is that the backend passthrough proxy is not forwarding query parameters from the proxy URL to the downstream Google API request.

Evidence:

• The CLI serializes query params identically for all platforms (via URLSearchParams)
• Google Calendar's List Events works because its query params may be handled differently by the proxy (e.g., as part of the action path or request body)
• Google Drive's Export endpoint specifically requires ?mimeType=text/plain on the final downstream URL, which the proxy isn't relaying

This needs a fix on the passthrough proxy service to forward query string parameters from the incoming request URL to the outbound API call.