Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix flaky errors with py3 #201

Closed
wants to merge 1 commit into from

Conversation

dnephin
Copy link
Contributor

@dnephin dnephin commented Feb 27, 2015

We ran into some test failures while using jsonschema==2.4.0 with python3. The failures were intermittent (approximately 1 in every 10 runs), but were reproducible in both py33 and py34 (py26 and py27 were unaffected).

You can see the failures in travis-ci for this PR Yelp/swagger_spec_validator#11 or use that branch to reproduce them (tox -e py34). The best example is test_success in this build.

The code calling jsonschema is pretty straightforward:

resolver = RefResolver('file://{0}'.format(schema_path), schema)
jsonschema.validate(json_document, schema, resolver=resolver)

The error is:

Unresolvable JSON pointer: 'definitions/simpleTypes'

I added a bunch of debugging to jsonschema to see what was happening. From what I can tell, RefResolver.resolve_fragment() is being called with a ref of definitions/simpleTypes but the current base_uri in the RefResolver is actually http://swagger.io/v2/schema.json instead of what it should be (http://json-schema.org/draft-04/schema).

I also noticed that the ordering was totally undefined, every run would produce a different call stack. Some orderings would fail, and some would succeed, but there was definitely more than one order which caused it to fail. I tried a few things, and found that adding this sorted() to iterations before descend() resolved the problem. I tried with list() as well, but that didn't solve the problem.

Without being able to completely explain the problem, I can say that this fixes it. My understanding is that some combination of the undefined order of fields, and the lazy evaluation of iteritems() causes some call stack which results in the wrong state.

@dnephin
Copy link
Contributor Author

dnephin commented Feb 28, 2015

It turns out that some part of #182 also fixes this bug

@dnephin
Copy link
Contributor Author

dnephin commented Mar 2, 2015

replaced by the solution in #203

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant