Closed Bug 1102864 Opened 10 years ago Closed 9 years ago

Better schema validation errors

Categories

(Taskcluster :: General, defect)

Product:
Taskcluster
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jhford, Assigned: jonasfj)

Details

fri, 21 Nov 2014 13:49:04 GMT base:api Error occurred handling: /v1/worker-type/testing, err: AssertionError: Type number must be a number, as JSON: {"name":"AssertionError","actual":"undefined","expected":"number","operator":"==","message":"Type number must be a number"}, incidentId: c23c660d-d3fc-4453-8cae-77efa1cb3510 AssertionError: Type number must be a number


This is far from being helpful.  It would be so much nicer if we could say *what* is not the right type.
To be clear this is a violation of base.Entity data type declaration, not a json schema validation error.

I'm well, aware these errors aren't very good. I'll see if I can make sure they are better in the next iteration of base.Entity that I'm currently implementing... I do in fact believe the new base.Entity will print the property name that you violated type restrictions for.
Assignee: nobody → jopsen
Status: NEW → ASSIGNED
Hmm... I think this was fixed with new base.Entity roll out...
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Component: TaskCluster → General
Product: Testing → Taskcluster
Target Milestone: --- → mozilla41
Version: unspecified → Trunk
Resetting Version and Target Milestone that accidentally got changed...
Target Milestone: mozilla41 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.