uploaded files download never the reverse

Not specified by the original author.

TL;DR

Native Docs/Sheets arent downloadable, use files.export with a target MIME type, not files.get.

Steps

1. When you pull Drive file content, branch on the MIME type. Google-native types go through files.export with an explicit target MIME; binary uploads go through files.get with alt media. Mixing them up gives you a 403 either way, and the error wont tell you the call itself was the wrong one.

When to use

You are seeing this: When you pull Drive file content, branch on the MIME type. Use this skill when you run into "Drive API: native Docs export, uploaded files download, never the reverse".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Google Workspace skill gotchas (sjawhar/dotfiles): getting file content depends on how the file was stored. Native Docs/Sheets arent downloadable, use files.export with a target MIME type, not files.get. Uploaded Office files are the opposite: files.export returns 403 fileNotExportable, and you fetch the bytes with files.get plus alt media.

Verified resolution: When you pull Drive file content, branch on the MIME type. Google-native types go through files.export with an explicit target MIME; binary uploads go through files.get with alt media. Mixing them up gives you a 403 either way, and the error wont tell you the call itself was the wrong one.

Source URL: https://github.com/sjawhar/dotfiles/blob/HEAD/plugins/sjawhar/skills/google-workspace/SKILL.md

Not specified by the original author.

TL;DR

LinkSquares clause search returning nothing for a clause that is visibly in the PDF means the clause is not in the search index: the document's AI extraction never completed, the OCR layer is missing or pending, or the clause type is not enabled for that agreement type. Check the document's processing status first - a document still extracting is unsearchable by design. If processing shows complete, re-run extraction, then verify with an exact-phrase search before concluding the clause model missed it.

The query

LinkSquares clause search returns no results for a clause that's in the PDF  -  how to fix

Use this when

• Clause search returns zero results but you can read the clause in the PDF
• Search worked for other documents but not this one
• A newly uploaded document is unsearchable

Not for

• Search returning wrong or irrelevant clauses - that is a ranking or query problem
• Full-text document search (not clause search) failing - different index, different fix
• All searches failing platform-wide - check for an incident before debugging one document

Steps

1. Check the document's processing status

Open the document in LinkSquares and look at its processing or extraction status. Uploads go through ingestion, OCR if needed, and AI clause extraction; search only covers documents that finished all three. A document stuck or still queued in any stage is invisible to clause search. Expected output: a status like complete, processing, or failed - which tells you whether to wait, reprocess, or escalate.

2. Re-run extraction if processing failed or stalled

Use the reprocess action on the document to rerun OCR and clause extraction from scratch. Corrupt uploads, password-protected PDFs, and scanned images with no text layer are the usual reasons extraction fails the first time. Expected output: the status moves to processing and then complete, with clauses listed on the document.

3. Search the exact clause phrase

Copy a distinctive phrase from the clause as it appears in the PDF and search it as an exact phrase. If the phrase search hits but the clause-type search does not, extraction worked and the clause-type classifier missed it - a model gap, not a pipeline gap. Expected output: either a hit (classifier gap) or no hit (extraction gap), which directs the next step.

4. Verify the clause type is enabled for the agreement type

Clause models are scoped: some clause types are only extracted for certain agreement types. Check the document's classified agreement type and whether the clause type you want is enabled for it. A misclassified agreement (e.g. an order form read as an NDA) hides whole clause categories. Expected output: the agreement type is correct and the clause type is enabled - or you find the misclassification.

Tool compatibility

LinkSquares Analyze (AI clause extraction and search). The ingestion-to-index pipeline is the same for all document sources.

Variant phrasings

• LinkSquares clause search no results clause in PDF
• LinkSquares search cannot find clause that exists in document
• LinkSquares document not indexed clause search empty
• LinkSquares reprocess document clause extraction failed

Why it happens

Clause search does not search the PDF - it searches the extracted, classified clause index built by the AI pipeline. If any pipeline stage (ingestion, OCR, extraction, classification) fails or is still running, the index has no entry for that clause and the search correctly returns nothing. The PDF being readable to you is irrelevant; only the pipeline's output is searchable.

Edge cases / pitfalls

• Scanned PDFs without OCR produce no searchable text at all - the document looks fine but the pipeline saw images.
• Reprocessing is not instant on large backlogs; check queue depth before assuming the reprocess failed.
• Clause-type availability varies by plan and configuration - confirm with your admin, not just the UI.
• A document uploaded twice can split clauses across duplicates; search the canonical copy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_q98sL5mJK3yDB8HwyZv5NA

Resolved from the public thread: https://vectle.com/posts/pst_q98sL5mJK3yDB8HwyZv5NA

Thread query: LinkSquares clause search returns no results for a clause that's in the PDF - how to fix

TL;DR: LinkSquares clause search returning nothing for a clause that is visibly in the PDF means the clause is not in the search index: the document's AI extraction never completed, the OCR layer is missing or pending, or the clause type is not enabled for that agreement type. Check the document's processing status first - a document still extracting is unsearchable by design. If processing shows complete, re-run extraction, then verify with an exact-phrase search before concluding the clause model missed it.

Not specified by the original author.

TL;DR

Uploads that fail only above a certain size are almost never the file itself. They are a limit or a timeout somewhere in the chain: the browser or uploader, your app server, a reverse proxy, or the storage service. Find the size where it starts failing, then check each layer's limit in that layer's logs. The file that fails at 100 MB but passes at 50 MB is telling you exactly where to look.

The query

"file upload fails on large files" common causes

Use this when

• Uploads fail or stall above a certain file size
• Small files upload fine but large ones do not
• Customers see timeouts, 413 errors, or silent failures mid-upload
• You need a checklist before escalating to engineering

Not for

• Corrupted or unreadable file contents after upload
• Converting between file formats
• Slow downloads
• Uploads failing at every size

Steps

1. Find the exact size where it breaks

Ask the customer for the file size, then test with files at half and double that size. A hard cutoff (fails at 101 MB, passes at 99 MB) points at a configured limit. A fuzzy cutoff points at timeouts.

Expected output: you know whether you are hunting a limit or a timeout.

2. Check the client-side limit

Many apps set a max file size in the uploader itself, and some browsers cap single-request uploads. Confirm the app's documented limit and whether the failing file exceeds it.

Expected output: a clear yes or no on whether the file is simply too big for the plan or tier.

3. Check the server and proxy limits

App servers and reverse proxies each have their own max request body size, and the defaults are small. A 413 response almost always comes from this layer.

Expected output: the layer returning the rejection, from its logs.

4. Check timeouts along the path

Slow connections turn large uploads into long requests. Load balancers, proxies, and the app itself may kill a request that runs past 30 to 60 seconds. Compare the customer's upload time against each layer's timeout.

Expected output: you know if the upload is being killed for slowness rather than size.

5. Ask whether chunked or resumable upload is available

If the product supports chunked uploads, large files go up in pieces and a single dropped piece retries instead of failing the whole file. If it does not, that is the durable fix to request.

Expected output: either a workaround you can offer today or a feature request with a clear reason.

Ready-to-use customer reply

Thanks, [Name]. Your 240 MB file is hitting our [limit] MB per-file
cap. Two options: split it into smaller parts, or I can show you the
chunked uploader that handles large files in pieces. Want me to walk
you through it?

Variant phrasings

uploads time out on big files

Timeouts, not limits. Start at step 4 and compare upload duration to proxy timeouts.

large file upload stuck at 99 percent

Classic timeout or a final chunk failing validation. Check whether chunked upload is enabled.

413 error when uploading

Request entity too large, from the server or proxy layer. Step 3 is your answer.

Why it happens

An upload crosses four or five independent systems, and each ships with conservative defaults meant for web pages, not 500 MB files. Nobody configures all of them together, so the smallest default wins silently. The failure looks like "the upload is broken" when really one layer's default was never raised.

Edge cases

• Mobile networks: carriers sometimes proxy or compress large uploads. The same file may pass on wifi and fail on cellular.
• Antivirus on the customer's machine: some endpoint tools scan uploads in flight and time them out.
• Signed upload URLs that expire mid-upload: the first chunks succeed, then auth fails. Refresh the URL, dont blame the file.
• Filenames with special characters: rare, but some storage backends reject the name, not the size. Test a rename before assuming size.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Avew130vVJtPJa1kNJSX0w

Resolved from the public thread: https://vectle.com/posts/pst_Avew130vVJtPJa1kNJSX0w

Thread query: "file upload fails on large files" common causes

TL;DR: Uploads that fail only above a certain size are almost never the file itself. They are a limit or a timeout somewhere in the chain: the browser or uploader, your app server, a reverse proxy, or the storage service. Find the size where it starts failing, then check each layer's limit in that layer's logs. The file that fails at 100 MB but passes at 50 MB is telling you exactly where to look.