property %q does not have a rangeable index to rebuild; use

Error message

property %q does not have a rangeable index to rebuild; use enable to create one

What it means

A rebuild needs an existing rangeable index to rebuild. If the property's IndexRangeFilters is nil or false, there is no range index, so the request is rejected with guidance to use the enable operation instead.

Source

Thrown at adapters/handlers/rest/handlers_reindex.go:128

			return fmt.Errorf("property %q is not a numeric type (int, number, date)", pn)
		}
		if prop.IndexRangeFilters != nil && *prop.IndexRangeFilters {
			return fmt.Errorf("property %q already has indexRangeFilters enabled", pn)
		}
	}
	return nil
}

// validateRebuildRangeableProperty is the inverse-precondition counterpart
// of validateRangeableProperties: the property must already have rangeable
// indexing enabled (otherwise there's nothing to rebuild — the caller
// wants enable-rangeable instead). Type must still be numeric/date.
func validateRebuildRangeableProperty(prop *models.Property) error {
	if !isNumericProperty(prop) {
		return fmt.Errorf("property %q is not a numeric type (int, number, date)", prop.Name)
	}
	if prop.IndexRangeFilters == nil || !*prop.IndexRangeFilters {
		return fmt.Errorf("property %q does not have a rangeable index to rebuild; use enable to create one", prop.Name)
	}
	return nil
}

// validateEnableFilterableProperty validates that the property is a
// suitable target for enable-filterable: it must not already have a
// filterable index, and its data type must support inverted filtering
// (everything except blob, geoCoordinates, and references).
func validateEnableFilterableProperty(prop *models.Property) error {
	if prop.IndexFilterable != nil && *prop.IndexFilterable {
		return fmt.Errorf("property %q already has a filterable index", prop.Name)
	}
	dt, ok := entschema.AsPrimitive(prop.DataType)
	if !ok {
		// Non-primitive (references) — not supported for filterable enable.
		return fmt.Errorf("property %q type %v does not support a filterable index", prop.Name, prop.DataType)
	}
	// Allow every primitive type EXCEPT the three below. Using a default

View on GitHub (pinned to 75aa4b6d11)

Solutions

Use the enable-rangeable operation first to create the index
Check models.Property.IndexRangeFilters before submitting a rebuild
Ensure you are targeting the correct collection/property (the flag may be set elsewhere)

Example fix

// before
rebuildRangeable(class, ["price"]) // no index yet
// after
enableRangeable(class, ["price"]) // creates the index first

Defensive patterns

Strategy: validation

Validate before calling

const p = schema.properties.find(p => p.name === name); if (p.indexRangeFilters !== true) return enableRangeable(className, [name]); // enable first

Type guard

function hasRangeIndex(p) { return p.indexRangeFilters === true }

Try / catch

try { await rebuildRangeable(className, [name]) } catch (e) { if (String(e).includes("does not have a rangeable index")) await enableRangeable(className, [name]); else throw e }

Prevention

Distinguish enable (create) vs rebuild (refresh) operations clearly
Verify IndexRangeFilters is true before scheduling rebuilds
When in doubt, enable first — rebuild only after enable succeeded

When it happens

Trigger: Calling rebuild-rangeable on a property that has no indexRangeFilters enabled (never enabled, or explicitly disabled).

Common situations: Confusing the enable and rebuild operations; property had range filters turned off earlier; new property added but never enabled.

Related errors

AI-assisted analysis of weaviate/weaviate@75aa4b6d11 (2026-09-04). Data as JSON: /api/errors/b98d1c46310d6fca. Report an issue: GitHub.