SigNoz/signoz · error
ErrCodePricingRuleInvalidInput
ErrCodePricingRuleInvalidInput
Error message
id is not a valid uuid
What it means
The LLM pricing rule handler failed to parse the {id} path variable as a UUID. ruleIDFromPath (pkg/modules/llmpricingrule/impllmpricingrule/handler.go:171-178) takes the mux route variable and calls valuer.NewUUID; if parsing fails the error is wrapped with ErrCodePricingRuleInvalidInput and returned as an invalid-input HTTP error. It means the client called a pricing-rule endpoint (GET/PUT/DELETE) with a malformed rule id.
Source
Thrown at pkg/modules/llmpricingrule/implllmpricingrule/handler.go:175
func ruleIDFromPath(r *http.Request) (valuer.UUID, error) {
raw := mux.Vars(r)["id"]
id, err := valuer.NewUUID(raw)
if err != nil {
return valuer.UUID{}, errors.Wrapf(err, errors.TypeInvalidInput, llmpricingruletypes.ErrCodePricingRuleInvalidInput, "id is not a valid uuid")
}
return id, nil
}View on GitHub (pinned to 5069bf80b0)
Solutions
- Verify the id value in the request URL is the exact UUID returned when the pricing rule was created
- Check for truncation/whitespace/percent-encoding in the path segment and re-send with the raw UUID
- If the frontend builds the URL from state, confirm that field actually stores the rule UUID and is populated
- Inspect server access logs for the full URL to spot the malformed segment
Example fix
// before curl -X DELETE https://signoz/api/v1/rules/rule-42 // after curl -X DELETE https://signoz/api/v1/rules/5f0c1b2e-3a44-4c9d-9e1f-7b8d6a2c0e55
Defensive patterns
Strategy: validation
Validate before calling
const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
if (!UUID_RE.test(ruleId)) throw new Error(`invalid rule id: ${ruleId}`);
await api.deleteRule(ruleId); Type guard
function isUUID(v: string): boolean {
return /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.test(v);
} Try / catch
try { await api.getRule(id); } catch (e) { if (e.code === 'pricing_rule_invalid_input') showUserError('Rule not found: bad id'); else throw e; } Prevention
- Always source rule ids from the create/list API responses, never construct them
- Validate UUID format client-side before building the URL
- URL-encode path segments to avoid encoding corruption
When it happens
Trigger: Any request to /api/v1/rules/{id} style LLM pricing rule routes where {id} is not a canonical UUID, e.g. 'rules/latest', 'rules/123', a truncated UUID, or a UUID with surrounding whitespace/percent-encoding issues.
Common situations: Hand-crafted curl calls, frontend passing an internal numeric id or a placeholder string instead of the UUID returned by the create endpoint, copy-paste truncation of the UUID, or stale client code using old id formats.
Related errors
AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28).
Data as JSON: /api/errors/e7129858455eca22.
Report an issue: GitHub.