weaviate/weaviate · error

data save error

Error message

data save error

What it means

After all classification item workers finish (wg.Wait), the work() routine stops the batch writer and compares the counts it recorded (successCount/errorCount) against the counts the batch writer actually reported. A mismatch means some object saves silently succeeded/failed outside the accounting (e.g. results were dropped or double-counted), so a synthetic 'data save error' is added to the error counter to fail the classification run rather than report a wrong success rate.

Source

Thrown at usecases/classification/classifier_run_worker.go:140

}

func (ws *runWorkers) work(ctx context.Context) runWorkerResults {
	ws.batchWriter.Start()

	wg := &sync.WaitGroup{}
	for _, worker := range ws.workers {
		worker := worker
		wg.Add(1)
		enterrors.GoWrapper(func() { worker.work(ctx, wg) }, ws.logger)

	}

	wg.Wait()

	res := ws.batchWriter.Stop()

	if res.SuccessCount() != *ws.successCount || res.ErrorCount() != *ws.errorCount {
		ws.ec.Add(errors.New("data save error"))
	}

	if res.Err() != nil {
		ws.ec.Add(res.Err())
	}

	return runWorkerResults{
		successCount: *ws.successCount,
		errorCount:   *ws.errorCount,
		err:          ws.ec.ToError(),
	}
}

type runWorkerResults struct {
	successCount int64
	errorCount   int64
	err          error
}

View on GitHub (pinned to 75aa4b6d11)

Solutions

1. Re-run the classification once the cluster is quiescent (no concurrent imports/deletes on the target collection).
2. Check res.Err() and the error counter (ws.ec) for the underlying write failure and fix that first (disk, shard availability).
3. If reproducible without concurrent writes, file a bug with logs — it indicates an internal count-accounting defect.

// Go — re-run classification when only accounting failed
err := classifier.Run(ctx, req)
if err != nil && strings.Contains(err.Error(), "data save error") {
    // check /v1/classifications/{id} status, then re-trigger once quiescent
    return retryClassificationAfterQuiesce(ctx, req)
}

When it happens

Trigger: batchWriter.Stop() returns a result whose SuccessCount()/ErrorCount() differ from the tallies kept by the worker shard (ws.successCount/ws.errorCount) — typically when objects were added/removed or the shard state changed mid-run, or an internal accounting race in the batch writer.

Common situations: Objects deleted or schema changed while a classification was running on a large dataset; concurrent writes to the same collection during classification; an aborted shard write whose outcome never got counted.

Related errors

• deadline exceeded for waiting for update
• read repair error
• conflict: object has been deleted on another replica
• cannot reach enough replicas
• opentelemetry: batch timeout must be greater than 0

AI-assisted analysis of weaviate/weaviate@75aa4b6d11 (2026-09-04). Data as JSON: /api/errors/2cc69b17429ae857. Report an issue: GitHub.