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
- 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).
- Alternatively use the BitFieldArgs.Builder, which tracks the current type automatically.
- 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
- Rule of thumb: the FIRST operation in a BITFIELD chain must use the typed overload.
- Prefer the BitFieldArgs.Builder so the current type is tracked automatically.
- When refactoring chains, check that removing a typed call doesn't orphan later type-less calls.
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
- Unknown plugin type!
- The Reactive Redis Client must be injected
- `count` must be strictly positive
- `pattern` must not be `null`
- Invalid integer encoding for a bit field type: " + bit + ".
AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05).
Data as JSON: /api/errors/69907ea34563fefe.
Report an issue: GitHub.