apache/beam · error · RuntimeException

Unexpected null number for

Error message

Unexpected null number for <field>

What it means

AutoValueSchema requires every AutoValue property used as a schema field to carry a @Nullable-annotated field number ordering check; here it found a FieldValueTypeInformation whose number is null. This means Beam could not determine the declared field index (from an annotation or generated metadata) for that AutoValue property.

Solutions

  1. Regenerate the AutoValue class (clean build) so generated metadata is present and consistent.
  2. Ensure the AutoValue class is annotated for schema use (e.g. @DefaultSchema(AutoValueSchema.class)) and properties are plain abstract getters.
  3. If supplying FieldValueTypeInformation manually, set field numbers explicitly.
  4. Check for conflicting schema annotation processors or stale generated classes in the build.

Example fix

// before
@AutoValue public abstract class Foo { public abstract Object getA(); }

// after: rebuild and use supported property types
@AutoValue @DefaultSchema(AutoValueSchema.class)
public abstract class Foo { public abstract String getA(); }
Defensive patterns

Strategy: validation

Validate before calling

for (FieldValueTypeInformation f : types) { if (f.getNumber() == null) throw new IllegalStateException("missing number: " + f.getName()); }

Try / catch

try { Schema.of(AutoValueClass.class); }
catch (RuntimeException e) { if (e.getMessage().startsWith("Unexpected null number")) { /* rebuild annotations / regenerate */ } throw e; }

Prevention

When it happens

Trigger: Calling Schema.of / schema inference on an AutoValue class (AutoValueSchema.schemaType / validateFieldNumbers) where a property lacks the expected field-number metadata (e.g. missing @AutoValue field ordering info or a schema annotation providing numbers).

Common situations: Mixing AutoValue classes annotated for Beam schema with plain getters; using an older/newer AutoValue generated class whose metadata Beam cannot read; manually built FieldValueTypeInformation lists in tests or custom type suppliers missing numbers.

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/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/a17010593ec56ef3. Report an issue: GitHub.

Appendix: source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/schemas/AutoValueSchema.java:78

              .filter(m -> !Modifier.isProtected(m.getModifiers()))
              .filter(m -> !m.isAnnotationPresent(SchemaIgnore.class))
              .collect(Collectors.toList());
      List<FieldValueTypeInformation> types = Lists.newArrayListWithCapacity(methods.size());
      for (int i = 0; i < methods.size(); ++i) {
        types.add(FieldValueTypeInformation.forGetter(typeDescriptor, methods.get(i), i));
      }
      types.sort(JavaBeanUtils.comparingNullFirst(FieldValueTypeInformation::getNumber));
      validateFieldNumbers(types);
      return types;
    }
  }

  private static void validateFieldNumbers(List<FieldValueTypeInformation> types) {
    for (int i = 0; i < types.size(); ++i) {
      FieldValueTypeInformation type = types.get(i);
      @javax.annotation.Nullable Integer number = type.getNumber();
      if (number == null) {
        throw new RuntimeException("Unexpected null number for " + type.getName());
      }
      Preconditions.checkState(
          number == i,
          "Expected field number %s for field %s instead got %s",
          i,
          type.getName(),
          number);
    }
  }

  @Override
  public <T> List<FieldValueGetter<@NonNull T, Object>> fieldValueGetters(
      TypeDescriptor<T> targetTypeDescriptor, Schema schema) {
    return JavaBeanUtils.getGetters(
        targetTypeDescriptor,
        schema,
        AbstractGetterTypeSupplier.INSTANCE,
        new DefaultTypeConversionsFactory());

View on GitHub (pinned to 12126d8942)