Dropping output field '{}' before writing to PubSub because

Error message

Dropping output field '{}' before writing to PubSub because this is a read-only column. To preserve this information you must configure a timestamp attribute.

What it means

In AddTimestampAttribute.expand, the output Row schema contains a TIMESTAMP_FIELD column, but the Pub/Sub sink was not configured with a timestamp attribute (useTimestampAttribute is false). Since Pub/Sub event timestamps map to publish time in that configuration, the read-only TIMESTAMP_FIELD column would be misleading, so it is dropped and a warning is logged. Data in that column is silently removed from the written output.

Source

Thrown at sdks/java/io/google-cloud-platform/src/main/java/org/apache/beam/sdk/io/gcp/pubsub/AddTimestampAttribute.java:64

    // element's event time. PubSubIO will populate the attribute from there.
    PCollection<Row> withTimestamp =
        useTimestampAttribute
            ? input.apply(
                WithTimestamps.of(
                    (row) ->
                        checkArgumentNotNull(
                                row.getDateTime(TIMESTAMP_FIELD),
                                "Field '%s' must be present and non-null in the input row when writing to PubSub with a timestamp attribute.",
                                TIMESTAMP_FIELD)
                            .toInstant()))
            : input;

    PCollection<Row> rows;
    if (withTimestamp.getSchema().hasField(TIMESTAMP_FIELD)) {
      if (!useTimestampAttribute) {
        // Warn the user if they're writing data to TIMESTAMP_FIELD, but event timestamp is mapped
        // to publish time. The data will be dropped.
        LOG.warn(
            "Dropping output field '{}' before writing to PubSub because this is a read-only "
                + "column. To preserve this information you must configure a timestamp attribute.",
            TIMESTAMP_FIELD);
      }
      rows = withTimestamp.apply(DropFields.fields(TIMESTAMP_FIELD));
    } else {
      rows = withTimestamp;
    }

    return rows;
  }
}

View on GitHub (pinned to 12126d8942)

Solutions

Call .withTimestampAttribute("<attribute-name>") on the Pub/Sub write so the event timestamp is preserved as a message attribute.
Remove TIMESTAMP_FIELD from the output schema if publish-time semantics are acceptable.
Rename the field if you intend it as ordinary data and want it kept (only TIMESTAMP_FIELD is dropped).
Review logs for this warning in CI to catch misconfigured Pub/Sub writes before production.

Example fix

// before
PubsubIO.writeRows().to(topic);
// after
PubsubIO.writeRows().to(topic).withTimestampAttribute("event_timestamp_attr");

Defensive patterns

Strategy: validation

Validate before calling

// before writing, check schema/config consistency
boolean ok = !withTimestamp.getSchema().hasField("event_timestamp")
          || writeTransform instanceof HasTimestampAttribute;

Type guard

boolean preservesTimestamp(PubsubIO.Write<Row> w) { return w != null && w.hasTimestampAttribute(); }

Prevention

Always pair a TIMESTAMP_FIELD column in the output schema with .withTimestampAttribute().
Assert schema/write-config consistency in pipeline unit tests.
Grep pipelines for TIMESTAMP_FIELD usages and audit each sink.
Treat this warning in CI logs as a build failure signal.

When it happens

Trigger: Writing a PCollection<Row> with a field named TIMESTAMP_FIELD (event_timestamp) to Pub/Sub via PubsubIO.write() without calling .withTimestampAttribute(); the expand() path drops the field before serialization.

Common situations: Users migrating from BigQuery sinks (where TIMESTAMP_FIELD is a real column) to Pub/Sub; SQL pipelines whose output schema includes event_timestamp but whose write config lacks withTimestampAttribute; copy-pasted sink configs that omit the attribute mapping.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors

AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/96944b375eea27eb. Report an issue: GitHub.