Bug #16884
closed
API server tests failing with "Didn't match" error
0%
Description
Background: when in test mode, as a correctness test the results of the incremental permission graph update is checked against a full recompute of the permission graph. They should always result in identical table contents.
This is sensitive to starting conditions. If the incremental update is done on a database where the materialized_permissions table was out of sync with the true permissions (the "full recompute" is assumed to be ground truth), then the result after the incremental update will also be wrong and we get the "Didn't match" error.
- developer-run-tests-services-api is failing, it seems random as there is no particular test that causes it to start failing.
developer-run-tests-services-api: #2210
developer-run-tests-services-api: #2212
developer-run-tests-services-api: #2213
developer-run-tests-services-api: #2218
- There is one success out of 5 attempts:
developer-run-tests-services-api: #2219
- When I run the tests locally, it passes.
Rails 5.2 has a few testing changes. Tests are shuffled so the order of test modules is different each time. Tests also share a database connection.
Updated by Peter Amstutz over 4 years ago
- Related to Bug #16811: Ensure that "public favorites" still work added
Updated by Peter Amstutz over 4 years ago
I think I might have found it, the fixtures were missing the permission link from anonymous users to public favorites, so if it restored from fixtures and didn't run database seeds, and computed the permissions from that, it would have the wrong permissions if it ran database seeds later. Added the permission to the fixtures, running here:
developer-run-tests-services-api: #2221 /console
However, I'm running locally and now I'm getting a new (probably unrelated) error:
1) Failure: UpdatePriorityTest#test_priority_0_but_should_be_>0 [/usr/src/arvados/services/api/test/unit/update_priority_test.rb:18]: Expected: 0 Actual: 1124298929949624
Updated by Peter Amstutz over 4 years ago
- Status changed from New to In Progress
- Assigned To set to Peter Amstutz
Updated by Peter Amstutz over 4 years ago
- Status changed from In Progress to Resolved