Gemini File Search API Not Returning Original File Names in Retrieved Chunks

Hi everyone,

I’m working with the Gemini File Search API for a RAG application and encountering an issue where the original file names (set via display_name during upload) aren’t returned in the retrieved_context of grounding chunks, especially in stores with multiple files.

Details:

  • When uploading PDFs to a File Search store, I explicitly set display_name to the original filename (e.g., “guideline.pdf”) using the SDK.

  • During queries with generateContent and the File Search tool enabled, the response’s grounding_metadata.grounding_chunks only includes text and fileSearchStore (the store ID). Fields like title, uri, or fileUri are missing or “NOT FOUND” in logs.

  • This happens consistently in multi-file stores; single-file stores sometimes infer the name, but it’s unreliable.

  • Expected: Per-chunk metadata should include the source file’s title for traceable citations, as hinted in docs and examples.

  • Actual: Only store-level info is provided, making it hard to map chunks back to specific documents without custom workarounds (e.g., separate stores per file).

What I’ve Tried:

  • Re-uploading with explicit display_name.

  • Parsing full chunk structures (e.g., chunk.retrieved_context.title).

  • Testing with small stores (1-5 files) and inspecting via logs.

  • No luck—metadata remains limited.

Environment: Google GenAI SDK (latest), Gemini 2.5 Flash model, multi-document stores under 20GB limit.

Has anyone else run into this? Is this a known limitation, or am I missing a config? Appreciate any insights or workarounds!

Thanks,

Hi @Jan_Martinek, welcome to the community!

Apologies for the delayed response.

To help us understand the issue better, could you please share a code snippet of what you’ve tried so far?

Thanks

Thank you for the follow-up. Here’s a brief recap and code snippets.

Issue recap:

When querying a File Search store, grounding_chunks in grounding_metadata don’t include title or uri (or fileUri) even though files are uploaded with display_name set to the original filename. This prevents identifying which file each chunk came from.

Environment:

  • Node.js (TypeScript)

  • @google/generative-ai (latest)

  • Gemini 2.5 Flash

  • File Search API

Code snippets:

1. Upload to store (setting display_name):
static async uploadToStore(
storeId: string,
filePath: string,
displayName?: string
): Promise {
// Use provided displayName (original filename) or fallback
const fileName = displayName || filePath.split(/[/\]/).pop() || ‘document.pdf’;
const fileData = fs.readFileSync(filePath);

let fileObj: File | Readable;
if (typeof File !== ‘undefined’) {
fileObj = new File([fileData], fileName, { type: ‘application/pdf’ });
} else {
fileObj = Readable.from(fileData);
}

// Set display_name explicitly - this is critical for title/uri to appear in chunks
const operation = await genAI.fileSearchStores.uploadToFileSearchStore({
fileSearchStoreName: storeId,
file: fileObj,
display_name: fileName, // snake_case format
} as any);

// … polling operation status …

return fileId;
}

2. Query with File Search tool (parsing grounding_chunks):
static async queryGuidelines(
storeId: string,
query: string
): Promise {
// Generate content with File Search tool
const result = await genAI.models.generateContent({
model: ‘gemini-2.5-flash’,
contents: query,
config: {
systemInstruction: systemInstruction,
tools: [{
fileSearch: {
fileSearchStoreNames: [storeId],
},
}],
},
} as any);

const response = (result as any).response || result;
const candidate = response.candidates?.[0];
const groundingMetadata = candidate?.groundingMetadata as any;
const groundingChunks = groundingMetadata?.groundingChunks ||
groundingMetadata?.groundingChuncks || ;

// Extract citations from grounding chunks
const citations = groundingChunks.map((chunk: any) => {
const retrievedContext = chunk.retrievedContext || {};
const text = retrievedContext.text || chunk.text || ‘’;

// Try multiple locations for file identifier - none are populated
const fileUri = retrievedContext.fileUri || 
               retrievedContext.title || 
               retrievedContext.uri ||
               chunk.fileUri || 
               chunk.uri ||
               chunk.title ||
               null; // Always null in practice

const pageNumber = chunk.pageNumber || 
                  retrievedContext.pageNumber || 
                  chunk.metadata?.pageNumber || 
                  null;

return {
  retrievedContext: {
    text: text,
    fileUri: fileUri, // Always null/undefined
    pageNumber: pageNumber,
  },
};

});

return {
text: response.text || /* extract from candidates */,
citations,
};
}

What we observe:

  • display_name is set during upload

  • grounding_chunks contain retrievedContext.text and pageNumber

  • retrievedContext.uri, retrievedContext.title, retrievedContext.fileUri, chunk.uri, chunk.title, etc. are missing

  • Only retrievedContext.fileSearchStore (store ID) is present, not individual file identifiers

Question:

Is this a known limitation, or is there a way to get the original filename (display_name) in the chunk metadata? If it’s a limitation, are there plans to add this?

Thanks for your help.

I experience the same problem

I’m using the filesearchstore with multiple files (each store maps to a folder in my app) and this would make citations impossible unless we create a store / file?

I am also facing the exact issue!

wow, it looks like this has actually been fixed now. In retrievedContext there’s now not onlya i ‘text’ property, but also a ‘title’ property that seems to be the displayName of the file.

I’ve done some testing and the API appears to be working correctly.

I took a closer look at your code, and I believe the issue is just a property name mismatch. The Node.js SDK expects displayName, but your code is using display_name. Because of this, the SDK is ignoring your custom filename and defaulting to the File ID, which is why you aren’t seeing the name you expected.

I made the changes you suggested and it’s working now! Not sure if there had been some issue in the File Store before, since I remebere I made some tests “Dispaly Name” names, but important is it’s working now.

Many thanks!
Jan