I’m facing a strange issue where Vertex AI Search (Discovery Engine) returns no results for a specific Google Workspace account, while it works perfectly for another account with identical settings.
Environment:
Data Source: Google Drive (Shared Drive)
Platform: Vertex AI Search (Discovery Engine)
Organization: Both accounts belong to the same Organizational Unit (OU).
The Problem:
Account A: Search results appear normally in both the API and the Google Cloud Console preview.
Account B: API response is empty (0 results), and no results appear in the Console preview.
What I’ve Verified (Identical for both accounts):
IAM Roles: Both have Discovery Engine Viewer (and other necessary roles).
Drive Permissions: Both have “Viewer” or higher access to the specific Shared Drive. Account B can manually open the files in Google Drive.
Service Agent: The Discovery Engine Service Agent has been granted the necessary permissions on the Drive.
Scopes: OAuth scopes are identical for both API requests.
Findings from Browser DevTools (Account B): When using the Cloud Console preview with Account B, I noticed the following errors in the Network tab:
404 Not Found for URLs related to cloudusersettings-...
429 Too Many Requests from https://accounts.google.com (Authentication related)
Questions:
Why would a specific account fail to retrieve search results when permissions are identical?
Are the 404 and 429 errors in the console related to the search results being empty, or are they red herrings?
Are there any specific user-level settings in Google Workspace or Cloud Identity that could block the ACL sync for Vertex AI Search?
I have already tried clearing the cache and using Incognito mode, but the issue persists. Any insights or suggestions on what to check next would be greatly appreciated.
Like the OP, our Workspace (Google Drive) Datastore works perfectly in the GCP Console Preview. However, querying via the Public API (Python v1beta SDK) using User ADC (gcloud auth application-default login with the exact same Workspace account) silently drops the documents and returns 0 results (only returning a generic summary).
Our engineering team ran some deep debugging on this, and here are what we found:
1. Identity is correctly passed to Discovery Engine: We enabled Data Access audit logs (ADMIN_READ + DATA_READ + DATA_WRITE). The logs clearly show ConversationalSearchService.AnswerQuery being hit, the principalEmail is correctly identified, and IAM permissions are successfully granted. So, the API absolutely knows who is making the request.
2. The API schema rejects Workspace ACL context workarounds: We suspected the API needed explicit user context to pass the Workspace file-level ACL check.
We tried passing userInfo.userIdToken via REST API. And it result 400 INVALID_ARGUMENT (unknown field userIdToken). The schema completely rejects it.
We then tried passing userInfo.userId = "``our-user@domain.com``". The API accepts this (200 OK), but still returns zero docs.
Conclusion: This proves the issue is not a malformed request or a missing IAM role. The Public API simply lacks the backend federation mechanism to validate Workspace file-level ACLs that the Console UI possesses. Because it can’t verify if the user has Drive permissions via the API request, it silently drops the documents to prevent data leakage.
We are submitting a formal public issue with these exact findings to the Google Cloud Issue Tracker, requesting clarification on whether there is an undocumented backend flag for API retrieval parity, or if this is officially a bug.
Has anyone found a workaround for this in the meantime? We are currently considering abandoning the Google Drive connector entirely and syncing our files to a GCS Bucket to bypass this Workspace ACL wall.
Thanks for your reply.
The files are stored in a Shared Drive. The file creator is different from both users, and ownership belongs to the Shared Drive rather than an individual user.