cockroachdb · jhlodin · Feb 4, 2026
diff --git a/src/current/advisories/a161317.md b/src/current/advisories/a161317.md
@@ -0,0 +1,75 @@
+---
+title: Technical Advisory 161317
+advisory: A-161317
+summary: A bug in CockroachDB's AVRO data import functionality can result in silent data loss when importing AVRO data using Object Container File (OCF) format. Storage backend errors (such as S3 read failures) might be silently ignored during these IMPORT operations, resulting in incomplete data imports without any error being reported to the user.
+toc: true
+affected_versions: v20.1 to v24.2, v24.3.0 to v24.3.25, All versions of v25.1, v25.2.0 to v25.2.11, v25.3.0 to v25.3.7, v25.4.0 to v25.4.3, All testing versions of v26.1 through v26.0-beta.3
+advisory_date: 2026-02-11
+docs_area: releases
+---
+
+Publication date: {{ page.advisory_date | date: "%B %e, %Y" }}
+
+## Impact
+
+A bug in CockroachDB's AVRO data import functionality can result in silent data loss when importing AVRO data using Object Container File (OCF) format. Storage backend errors (such as S3 read failures) might be silently ignored during these IMPORT operations, resulting in incomplete data imports without any error being reported to the user.
+
+This advisory applies to the following versions of CockroachDB:
+
+- v20.1 through v24.2
+- v24.3.0 through v24.3.25
+- All versions of v25.1
+- v25.2.0 to v25.2.11
+- v25.3.0 to v.25.3.7
+- v25.4.0 to v.25.4.3
+- All testing versions of v26.1 through v26.1.0-beta.3 
+
+## Statement
+
+This is resolved in CockroachDB by PR [#161318](https://github.com/cockroachdb/cockroach/pull/161318) which fixes the improper error handling in the AVRO OCF reader implementation.
+
+This fix has been applied to the following maintenance releases of CockroachDB:
+
+- v24.3.26
+- v25.2.12
+- v25.4.4
+- Testing release v26.1.0-rc.1
+
+This public issue is tracked in [161317](https://github.com/cockroachdb/cockroach/issues/161317).
+
+## Mitigation
+
+Users of affected CockroachDB versions are encouraged to upgrade to v24.3.26, v25.2.12, v25.4.4, v26.1.0-rc.1, or a later version.
+Users on affected versions can determine whether they may have encountered the problem by searching their logs to detect any errors during IMPORT jobs that improperly succeeded. If the logs indicate a potential issue, users should contact support and work through the appropriate manual validation steps.
+
+For details, refer to [Detection via logs](#detection-via-logs) and [Manual validation](#manual-validation). Reach out to our [support team](https://support.cockroachlabs.com/) if more information or assistance is needed.
+
+### Detection via logs
+
+If an IMPORT of an AVRO data file using OCF format succeeded, the logs may indicate that an error caused some data to be missed. Note that some errors are retried automatically and transparently, so although an error might have occurred, a successful retry would prevent any data loss. If there was no retry or if the retry was unsuccessful, an error message would be logged indicating possible data loss. The exact error message varies depending on the CockroachDB version and the cloud storage service used, for example:
+
+~~~ text
+E260109 13:32:59.076601 120905097 cloud/cloud_io.go:326 ⋮ [T1,Vsystem,n9,fee22d333,job=0123456789012345678,distsql.gateway=6,distsql.appname=‹$ internal-resume-job-0123456789012345678›] 89452 read ‹path/to/filename.avro›: ‹stream error: stream ID 3; CANCEL; received from peer›
+~~~
+
+To find relevant log lines, use the following commands to search your logs depending on your version of CockroachDB:
+
+- v21.1: `grep -R -E 'storage/cloudimpl/external_storage\.go:546.*Read err:.*' <logs-path>`
+- v21.2-v22.1: `grep -R -E 'cloud/cloud_io\.go.*Read err:.*' <logs-path>`
+- v22.2 or later: `grep -R -E 'cloud/cloud_io\.go.*read .*' <logs-path>`
+
+If these commands do not find any applicable log entries from the time period while an IMPORT was running, your cluster was not affected by this issue during the log retention period. If applicable log entries are found or an IMPORT job ran during a timespan for which you have no logs, you can manually validate the job using one of the relevant methods described in [Manual validation](#manual-validation).
+
+### Manual validation
+
+This section contains mitigation steps for IMPORT jobs affected by this issue.
+
+IMPORT jobs affected by this issue could be missing rows that were present in the source data. To check whether a suspected IMPORT job was affected, compare the number of rows imported with the number of rows in the source data.
+
+Follow these steps after you find a problematic error in the logs and you have contacted support, or if you want to manually validate a job for which you have no logs:
+
+1. If the output of the IMPORT statement showed the expected number of rows, then the import was unaffected.
+1. After a successful IMPORT job, there should be a `RecoveryEvent` logged to the TELEMETRY logging channel with `"RecoveryType": "import_job"`. If `NumRows` from this event shows the expected number of rows, then the import was unaffected.
+1. If the logged row count indicates missing rows, or you otherwise suspect that the IMPORT may have been incomplete, the recommended approach is to re-run the IMPORT using a fixed version of CockroachDB, loading the data into a second table. You can then compare the two datasets using a JOIN to identify rows that may be missing from the original import, and manually reconcile any discrepancies.
+  - In many cases, this comparison can be done directly against the existing table. Rows may appear as “missing” if they failed to import originally, or if they were subsequently updated or deleted. Depending on the workload, these cases may be distinguishable through application logic or other logs.
+  - If you choose to use retained backups that cover the relevant time window, an alternative is to restore a copy of the table as it existed shortly after the original IMPORT completed (using RESTORE … AS OF SYSTEM TIME) and compare row counts or join against that restored table. This can help isolate rows that failed to import specifically. However, this approach depends on backup availability and retention, and may be more time-consuming than comparing against the existing table.