SigNoz/signoz · error · errors.Error

CodeLicenseUnavailable

CodeLicenseUnavailable

Error message

a valid license is not available

What it means

Default branch of the filter-operator switch in PrepareTimeseriesFilterQueryV3 (SigNoz metrics v4 helpers building v3-compatible sub-queries). It fires when a filter item's operator has no corresponding ClickHouse condition emitted by this function, unlike its siblings like/nlike/exists/nexists handled just above the default.

Source

Thrown at ee/authn/callbackauthn/samlcallbackauthn/authn.go:69

	}

	return url, nil
}

func (a *AuthN) HandleCallback(ctx context.Context, formValues url.Values) (*authtypes.CallbackIdentity, error) {
	state, err := authtypes.NewStateFromString(formValues.Get("RelayState"))
	if err != nil {
		return nil, errors.New(errors.TypeInvalidInput, authtypes.ErrCodeInvalidState, "saml: invalid state").WithAdditional(err.Error())
	}

	authDomain, err := a.store.GetAuthDomainFromID(ctx, state.DomainID)
	if err != nil {
		return nil, err
	}

	_, err = a.licensing.GetActive(ctx, authDomain.StorableAuthDomain().OrgID)
	if err != nil {
		return nil, errors.New(errors.TypeLicenseUnavailable, errors.CodeLicenseUnavailable, "a valid license is not available").WithAdditional("this feature requires a valid license").WithAdditional(err.Error())
	}

	samlConfig, err := authDomain.Config().SamlConfig()
	if err != nil {
		return nil, err
	}

	sp, err := a.serviceProvider(state.URL, authDomain)
	if err != nil {
		return nil, err
	}

	assertionInfo, err := sp.RetrieveAssertionInfo(formValues.Get("SAMLResponse"))
	if err != nil {
		if errors.As(err, &saml2.ErrVerification{}) {
			return nil, errors.New(errors.TypeForbidden, errors.CodeForbidden, err.Error())
		}

View on GitHub (pinned to 5069bf80b0)

Solutions

  1. Inspect each item.Operator in qp.Filters and map it to a supported one (=, !=, in, nin, like, nlike, ilike, nlike-ci variants, exists, nexists)
  2. Pin or align SigNoz versions so the v4-compat builder covers the operators your dashboards use
  3. Pre-validate filters against an allowlist before calling the builder and surface a field-level error to users

Example fix

// before
{"key":"service.name","operator":"regex","value":"web.*"}

// after
{"key":"service.name","operator":"contains","value":"web"} // or 'like' with a ClickHouse-compatible pattern
Defensive patterns

Strategy: validation

Validate before calling

for _, f := range qp.Filters {
	switch f.Operator {
	case v3.FilterOperatorEqual, v3.FilterOperatorNotEqual, v3.FilterOperatorIn, v3.FilterOperatorNotIn, v3.FilterOperatorLike, v3.FilterOperatorNotLike, v3.FilterOperatorExists, v3.FilterOperatorNotExists, v3.FilterOperatorRegex:
	default:
		return fmt.Errorf("filter %s uses unsupported operator %s", f.Key.Key, f.Operator)
	}
}

Type guard

null

Try / catch

if _, err := helpers.PrepareTimeseriesFilterQueryV3(...); err != nil && strings.Contains(err.Error(), "unsupported filter operator") {
	// log the filter item and drop it, then retry the build
}

Prevention

When it happens

Trigger: A v3-format metrics query executed through the v4 optimized path (buildMetricQueryForTable / buildDeltaMetricQuery / buildDeltaMetricQueryForTable / buildMetricQuery) with a filters entry whose operator is not implemented — typo'd operator string, numeric comparator on a label, or an operator added elsewhere only.

Common situations: Dashboards built on older SigNoz versions replayed against a newer v4 code path with a narrower operator set; API clients copying filter JSON from traces (v3.FilterOperator vocabulary) into metrics queries; fork customizations adding operators to only one builder.

Related errors


AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28). Data as JSON: /api/errors/85650824be44ce9e. Report an issue: GitHub.