mongodb-partners/mongo-rocks

rocks_record_store_test fails with latest changes in master

igorsol opened this issue · 7 comments

storage_rocks_record_store_test fails with the changes made after r3.5.10.
Here is console snippet with failure:

2017-08-02T14:22:51.992+0300 I -        [main] going to run suite: ValidateTest
2017-08-02T14:22:51.992+0300 I -        [main] 	 going to run test: ValidateNonEmpty
2017-08-02T14:22:51.992+0300 I -        [main] Created temporary directory: /tmp/mongo-rocks-record-store-test-edd1-80c8-65ff-a441
2017-08-02T14:22:52.000+0300 E -        [main] Throwing exception: Expected: 1 == _remain.erase(s) @src/mongo/db/storage/record_store_test_validate.h:51
2017-08-02T14:22:52.005+0300 I -        [main] FAIL: ValidateNonEmpty	Expected: 1 == _remain.erase(s) @src/mongo/db/storage/record_store_test_validate.h:51
2017-08-02T14:22:52.005+0300 I -        [main] 	 going to run test: ValidateAndScanDataNonEmpty
2017-08-02T14:22:52.006+0300 I -        [main] Created temporary directory: /tmp/mongo-rocks-record-store-test-ba6a-2b19-97a7-9f08
2017-08-02T14:22:52.016+0300 E -        [main] Throwing exception: Expected: 1 == _remain.erase(s) @src/mongo/db/storage/record_store_test_validate.h:51
2017-08-02T14:22:52.019+0300 I -        [main] FAIL: ValidateAndScanDataNonEmpty	Expected: 1 == _remain.erase(s) @src/mongo/db/storage/record_store_test_validate.h:51
2017-08-02T14:22:52.022+0300 I -        [main] 	 going to run test: FullValidateNonEmptyAndScanData
2017-08-02T14:22:52.022+0300 I -        [main] Created temporary directory: /tmp/mongo-rocks-record-store-test-b13d-5357-0cf1-80ea
2017-08-02T14:22:52.035+0300 I -        [main] 	 DONE running tests
2017-08-02T14:22:52.035+0300 I -        [main] **************************************************
2017-08-02T14:22:52.035+0300 I -        [main] RecordStoreTestHarness         | tests:   53 | fails:    0 | assert calls:          0 | time secs:  0.840
2017-08-02T14:22:52.035+0300 I -        [main] RecordStore_CappedVisibility   | tests:    2 | fails:    0 | assert calls:          0 | time secs:  0.014
2017-08-02T14:22:52.035+0300 I -        [main] RocksRecordStoreTest           | tests:   10 | fails:    0 | assert calls:          0 | time secs:  0.132
2017-08-02T14:22:52.035+0300 I -        [main] ValidateTest                   | tests:    3 | fails:    2 | assert calls:          0 | time secs:  0.042
	ValidateNonEmpty	Expected: 1 == _remain.erase(s) @src/mongo/db/storage/record_store_test_validate.h:51
	ValidateAndScanDataNonEmpty	Expected: 1 == _remain.erase(s) @src/mongo/db/storage/record_store_test_validate.h:51
2017-08-02T14:22:52.035+0300 I -        [main] TOTALS                         | tests:   68 | fails:    2 | assert calls:          0 | time secs:  1.028
2017-08-02T14:22:52.035+0300 I -        [main] Failing tests:
2017-08-02T14:22:52.035+0300 I -        [main] 	 ValidateTest/ValidateNonEmpty Failed
2017-08-02T14:22:52.035+0300 I -        [main] 	 ValidateTest/ValidateAndScanDataNonEmpty Failed
2017-08-02T14:22:52.035+0300 I -        [main] FAILURE - 2 tests in 1 suites failed

Hmm, I'm assuming this was 1d75834, which is strange. I'll take a look.

Hey @igorsol , I just tried this locally and the test works for me. Do you have 1d75834 in your tree?

Hi @igorcanadi , Yes my tree contains 1d75834. I merged 59458f2 into our master branch and this causes storage_rocks_record_store_test to fail. Before that I tested with r3.5.10 and the test succeeded. So the issue appeared somewhere between r3.5.10 and 59458f2
I will try to find exact commit.

Yes, I reverted 1d75834 and now the unit test succeeds.

@igorsol this sounds like 1d75834 was a commit required by an equivalent change in mongo. I am not sure what is the change on the mongo side, but can you update your master to the current mongo's master and try again? If you look at the Mongo tests, you'll see that they are green: https://evergreen.mongodb.com/build_variant/mongodb-mongo-master/ubuntu1404-rocksdb

@igorcanadi you are right. It works fine with 3.5.11. My fail was to test mongo-rocks 3.5.11 with server versions 3.5.10 and 3.5.9.
Closing the issue.

Awesome!