=== Attempt 1/3 ===
curl -X POST '.../upload_file' -F 'file=@04c_mixed_sheet_usgs-earthquakes.csv;filename=04c_nondeterminism_test_1.txt;type=text/plain'
Captured at 2026-08-18T22:32:26Z
{"messages":["mime-type 'text/csv' not supported."],"request_id":"91bdac52-429c-41b8-afc4-75f823d993f4"}
HTTP_STATUS:415

cleanup_status:404
=== Attempt 2/3 ===
curl -X POST '.../upload_file' -F 'file=@04c_mixed_sheet_usgs-earthquakes.csv;filename=04c_nondeterminism_test_2.txt;type=text/plain'
Captured at 2026-08-18T22:32:33Z
{"id":"04c_nondeterminism_test_2.txt","metadata":{"X-TIKA:Parsed-By":"org.apache.tika.parser.csv.TextAndCSVParser","Content-Encoding":"UTF-8","X-TIKA:detectedEncoding":"UTF-8","csv:delimiter":"comma","X-TIKA:encodingDetector":"UniversalEncodingDetector","Content-Type":"text/csv; charset=UTF-8; delimiter=comma"},"storage_usage":{"bytes_used":115585,"metadata_bytes_used":693}}
HTTP_STATUS:201

cleanup_status:204
=== Attempt 3/3 ===
curl -X POST '.../upload_file' -F 'file=@04c_mixed_sheet_usgs-earthquakes.csv;filename=04c_nondeterminism_test_3.txt;type=text/plain'
Captured at 2026-08-18T22:32:39Z
{"id":"04c_renamed.txt","metadata":{"X-TIKA:Parsed-By":"org.apache.tika.parser.csv.TextAndCSVParser","Content-Encoding":"UTF-8","X-TIKA:detectedEncoding":"UTF-8","csv:delimiter":"comma","X-TIKA:encodingDetector":"UniversalEncodingDetector","Content-Type":"text/csv; charset=UTF-8; delimiter=comma"},"storage_usage":{"bytes_used":115585,"metadata_bytes_used":693}}
HTTP_STATUS:201

cleanup_status:404

=== Result: 2/3 succeeded (415, 201, 201) ===
Combined with the original 3 failures + 1 success from the prior round, the disguised-CSV trick's
overall observed record is 2 successes out of 6 attempts - genuinely non-deterministic, not "usually
fails with rare flakes" or "usually works." Native .csv (undisguised) has been 100% rejected (415)
every time it's been tried, by contrast.

SECOND FINDING - content-based deduplication: attempt 3 requested filename
"04c_nondeterminism_test_3.txt" but the server returned id "04c_renamed.txt" instead - the id of a
DIFFERENT document (with identical byte content) uploaded and deleted in an earlier test. This means
Vectara appears to key documents by content hash, not by the requested filename: uploading
byte-identical content under a new name can silently resurrect/reuse a prior document's id rather
than creating a distinctly-named new document. This caused the delete-by-requested-name cleanup to
fail (404, since that id was never created) - the actual leftover document (04c_renamed.txt) had to
be found via a fresh document-list call and deleted separately. Corpus verified back to a clean 11
documents after cleanup (see re-verification in this same evidence set).