quarkusio/quarkus · error · IllegalStateException

No previous field type found

Error message

No previous field type found

What it means

In BitFieldArgs, the GET/SET/INCRBY variants without an explicit BitFieldType reuse the field type from a previous chained command (previousBitFieldType). getPreviousFieldType() throws this IllegalStateException when the BITFIELD command starts with a type-less GET/SET/INCRBY, so there is no prior type to inherit. Redis BITFIELD requires a type for the first operation.

Source

Thrown at extensions/redis-client/runtime/src/main/java/io/quarkus/redis/datasource/bitmap/BitFieldArgs.java:348

     */
    public static Offset offset(int offset) {
        return new Offset(false, offset);
    }

    /**
     * Creates a new {@link Offset} for the given {@code offset} that is multiplied by the integer type width used in the sub
     * command.
     *
     * @param offset offset to be multiplied by the integer type width.
     * @return the {@link Offset}.
     */
    public static Offset typeWidthBasedOffset(int offset) {
        return new Offset(true, offset);
    }

    private BitFieldType getPreviousFieldType() {
        if (previousBitFieldType == null) {
            throw new IllegalStateException("No previous field type found");
        } else {
            return previousBitFieldType;
        }
    }

    public List<Object> toArgs() {
        return commands;
    }

}

View on GitHub (pinned to e1c734241f)

Solutions

  1. Start the chain with a typed overload: set(BitFieldType.INT_8, offset, value), get(BitFieldType.INT_8, offset), or incrBy(BitFieldType.INT_8, offset, value).
  2. Alternatively use the BitFieldArgs.Builder, which tracks the current type automatically.
  3. Reorder the fluent chain so a typed call precedes any type-less call.

Example fix

// before
BitFieldArgs args = new BitFieldArgs().get(0); // IllegalStateException
// after
BitFieldArgs args = new BitFieldArgs().get(BitFieldType.UINT_8, 0);
Defensive patterns

Strategy: type-guard

Validate before calling

BitFieldArgs args = new BitFieldArgs();
if (typedCallFirst) {
    args.set(BitFieldType.INT_8, offset, value); // establish the type first
} else {
    args.get(BitFieldType.UINT_8, offset); // never start with the type-less overload
}

Type guard

boolean hasPreviousType(BitFieldArgs args) { return args.toArgs().stream().anyMatch(a -> String.valueOf(a).matches("(i|u)\\d+")); }

Try / catch

try { return args.get(offset); } catch (IllegalStateException e) { if (e.getMessage().contains("No previous field type")) { return args.get(BitFieldType.INT_16, offset); } throw e; }

Prevention

When it happens

Trigger: Calling bfa.get(offset) or bfa.set(offset, value) or bfa.incrBy(offset, value) (the type-less overloads) as the FIRST operation on a fresh BitFieldArgs instance — e.g. new BitFieldArgs().get(0) or new BitFieldArgs().incrBy(offset, 1).

Common situations: Building a single-operation BITFIELD command and assuming the type-less overload is self-sufficient; copying code that worked because a earlier .set(bft, ...) call established the type, then removing that call; ordering methods so the typed call comes after the type-less one.

Related errors


AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/69907ea34563fefe. Report an issue: GitHub.