apache/druid · error · ISE

Failed to add a row with timestamp[%s]

Error message

Failed to add a row with timestamp[%s]

What it means

During IndexTask row ingestion, the sink/appendeable failed to accept an input row (e.g. the segment sink is full, closed, or the row could not be added after retries). The processor aborts with ISE, treating it as an unrecoverable ingestion failure rather than dropping the row.

Source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/common/task/InputSourceProcessor.java:132

        if (addResult.isOk()) {
          // incremental segment publishment is allowed only when rollup doesn't have to be perfect.
          if (dynamicPartitionsSpec != null) {
            final boolean isPushRequired = addResult.isPushRequired(
                dynamicPartitionsSpec.getMaxRowsPerSegment(),
                dynamicPartitionsSpec.getMaxTotalRowsOr(DynamicPartitionsSpec.DEFAULT_MAX_TOTAL_ROWS)
            );
            if (isPushRequired) {
              // There can be some segments waiting for being pushed even though no more rows will be added to them
              // in the future.
              // If those segments are not pushed here, the remaining available space in appenderator will be kept
              // small which could lead to smaller segments.
              final SegmentsAndCommitMetadata pushed = driver.pushAllAndClear(pushTimeout);
              segmentSchemaMapping.merge(pushed.getSegmentSchemaMapping());
              LOG.debugSegments(pushed.getSegments(), "Pushed segments");
            }
          }
        } else {
          throw new ISE("Failed to add a row with timestamp[%s]", inputRow.getTimestamp());
        }
      }

      final SegmentsAndCommitMetadata pushed = driver.pushAllAndClear(pushTimeout);
      segmentSchemaMapping.merge(pushed.getSegmentSchemaMapping());
      LOG.debugSegments(pushed.getSegments(), "Pushed segments");

      return Pair.of(pushed, segmentSchemaMapping);
    }
  }
}

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Inspect task logs immediately preceding this error for sink allocation or push failures and fix the root cause
  2. Adjust query granularity/segment granularity so rows fall into valid buckets, or widen the task's windowPeriod for late data
  3. Retry the failed task; if caused by transient push timeouts, increase pushTimeout or deep-storage retry settings

Example fix

// before
// rows with timestamps far outside segmentGranularity buckets
// after
// set proper granularitySpec.rollup + query granularity, and configure
// taskContext "maxRowsInMemory" so sinks flush before contention
Defensive patterns

Strategy: try-catch

Try / catch

try { runIngestion(spec); } catch (ISE e) { if (e.getMessage().startsWith("Failed to add a row")) { retryTaskWithAdjustedWindows(spec); } else { throw e; } }

Prevention

When it happens

Trigger: driver.add(...) returns false for an input row, e.g. when the current sink is sealed/being pushed and a new sink cannot be created, or push/allocate failures leave no active sink for the row's timestamp.

Common situations: Very high late-arrival data hitting rows outside the windowPeriod while sinks are mid-push; task being killed/closed concurrently; tuning maxRowsInMemory/delayed flush so pushes race with row arrival.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/f4539d59a3eb0f5a. Report an issue: GitHub.