fix(google-workspace): surface Shared Drive docs in Drive search via corpora#59
Open
xBalbinus wants to merge 1 commit into
Open
fix(google-workspace): surface Shared Drive docs in Drive search via corpora#59xBalbinus wants to merge 1 commit into
xBalbinus wants to merge 1 commit into
Conversation
…corpora Drive list/search default to corpora='user', which is My Drive only and excludes files that live in a Shared Drive (Team Drive) — so team/shared docs silently never appear in search. The supportsAllDrives / includeItemsFromAllDrives flags don't help: they are capability flags, not corpus-wideners. (The root cause is the corpus, not the OAuth scope — the integration already holds the full auth/drive grant.) Conservative fix (no change to the default corpus): - Rewrite the tool descriptions and the google-drive skill to state that 'user' excludes Shared Drives and to use corpora='allDrives' for team/shared docs or when a default search comes up empty. - Remove the dead 'drive' corpus value: it requires a driveId no action sends (always 400s) and cannot be stored as an org setting. 'allDrives' already covers shared drives. - Add an e2e test that drives executeDriveAction with a mocked Drive API: asserts the default stays 'user', that opting into 'allDrives' (per-request or org setting) returns a shared-drive doc, and that the removed 'drive' value is rejected. Drive-by: classify docs.find_text_index in the labels guard. It was registered but uncategorized, so it was fail-closed-denied when the guard is active and broke the guard's classification-completeness test. Widening the org-wide default corpus to 'allDrives' is deferred as a separate product decision.
|
Preview deployment: https://pr-59.dev-valet-turnkey-client.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Google Drive search misses certain docs — specifically anything that lives in a Shared Drive (Team Drive). Personal and directly-shared docs return fine; team/project/company docs in Shared Drives silently never appear.
Root cause (it's the corpus, not the OAuth scope)
Every Drive list/search defaults to
corpora='user'(drive-actions.ts). Per Google'sfiles.listspec, the'user'corpus is "files owned by or shared to the user" and excludes files resident in a Shared Drive. ThesupportsAllDrives+includeItemsFromAllDrives=trueflags we already send don't help — they're capability flags, not corpus-wideners. To reach shared drives you must usecorpora='allDrives'.The integration already requests the full
https://www.googleapis.com/auth/drivescope, so the token can see these docs — the query just never asks for them. The OAuth-scope theory is a red herring here.What this PR does (conservative — no default behavior change)
This is the low-risk path: it does not change the default corpus org-wide. Instead it makes
allDrivesreliable and discoverable:google-driveskill so the agent knows'user'excludes Shared Drives and reaches forcorpora:'allDrives'for team/shared docs (or when a default search returns nothing).'drive'corpus value — it requires adriveIdno action sends (always 400s) and can't be stored as an org setting (OrgSettings.driveCorporais'user' | 'domain' | 'allDrives').'allDrives'already covers shared drives.drive-search-corpora.test.ts) drivesexecuteDriveActionagainst a mocked Drive API and asserts: default stays'user'; opting into'allDrives'(per-request or the orgdriveCorporasetting) returns a shared-drive doc; the removed'drive'value is rejected without hitting the API.Drive-by
Classify
docs.find_text_indexin the labels guard. It was registered but uncategorized, so it was fail-closed-denied whenever the guard is active, and it broke the guard's classification-completeness test (already red onmain). One-line fix → suite is green.Deferred (separate decision)
Widening the org-wide default corpus from
'user'→'allDrives'(resolver + org default + a migration flipping existing rows) would fix this automatically for every org, but it's a behavioral change with a privacy-perception angle and Google's "incomplete results on very large workspaces" caveat. Flagged to @yourbuddyconner (TKAI-49 author) as its own call.Test plan
drive-search-corpora.test.ts— 6 new e2e cases ✅resolve-corpora.test.ts— updated for'drive'removal ✅labels-guard.test.ts— now green (find_text_indexclassified) ✅tsc --noEmitclean