If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Better schema validation errors

RESOLVED FIXED

Status

Taskcluster
General
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: jhford, Assigned: jonasfj)

Tracking

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.
(Assignee)

Comment 1

3 years ago
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
(Assignee)

Comment 2

3 years ago
Hmm... I think this was fixed with new base.Entity roll out...
Status: ASSIGNED → RESOLVED
Last Resolved: 3 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.