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

WIP: Riak KV 1329 tests #981

Closed

Conversation

lukebakken
Copy link
Contributor

Adding tests for 2i exact match scenarios

See basho/riak_kv#1329

zeeshanlakhani and others added 14 commits October 13, 2015 15:35
…s-as-per-PR866

yokozuna_rt additions for types and better testing w/ allow-mult=true…
Add debugging to rt:do_commit/1 to track nothing_planned
sure up possible race between upgrade and first check
- update `prepare` so that it waits for the vnode PID to change as it's
  possible that monitors haven't fired by the time we ask for a new one
- Update `drain` to require 3 consecutive 0 counts from a group of PIDs
  rather than draining individual processes or only trying once. The
  number 3 was determined empirically - read the comment above `drain`
  if it continues to cause issues.
- Rewrite `resume` to make sure things are drained properly before
  continuing.
…_2.0

Update proxy_overload_recovery to handle indeterminism more gracefully.
We've run into a number of issues over time where errant processes hang
around and stomp on other tests, and without PIDs in the logging it can
be difficult or impossible to conclusively identify and debug these
kinds of problems.
Previously, wait_until_read function would execute
another rt:systest_read call and return a count of
errors, when we already asserted above that the list
is empty.

If the wait_until function does not return true, or
times out, or hits the retry limit, the running test
ought to fail anyway without needing an additional
read to fail.

So doing another call is redundant and unnecessary;
we just return 0 as the value if rt:wait_until
completes successfully.
Log PIDs by default for console output
Return 0 instead of doing another rt:sysread in repl_util:wait_for_reads/5
assertEqual(RiakHttp, PBPid, ExpectedKeys, {<<"$key">>, int_to_key(0), int_to_key(999)}, ?Q_OPTS, keys),
assertEqual(RiakHttp, PBPid, ExpectedKeys, { <<"$bucket">>, ?BUCKET}, ?Q_OPTS, keys),

ExpectedFooKeys = lists:sort([int_to_key(N) || N <- lists:seq(101, 200)]),
assertEqual(RiakHttp, PBPid, ExpectedFooKeys, {<<"field1_bin">>, ?FOO}, ?Q_OPTS, keys),

assertEqual(RiakHttp, PBPid, [int_to_key(201)], {<<"field1_bin">>, ?BAZ}, ?Q_OPTS, keys),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make sure to put some comments around/before the newly added expectations so we know why they were added and what they are testing.

@hazen
Copy link

hazen commented Jan 26, 2016

@lukebakken Would you mind doing this on the riak/2.0 branch, assuming this is appropriate for that version too? master is the end of the line, not the start these days. The merge order today is riak/2.0 -> riak/2.1 -> riak-ts_develop-1.2. We should update master from riak/2.1 soon, too.

@JeetKunDoug
Copy link
Contributor

Funny - see #977 @javajolt . Agreed that this should happen on the riak/2.0 branch - sorry I hadn't caught it earlier.

@lukebakken
Copy link
Contributor Author

@javajolt - I'll do that when I get a chance.

@lukebakken lukebakken force-pushed the fixes/lrb/riak_kv-1329-2i-exact-match-bucket-type branch from bebc8f8 to 3a6a2bc Compare January 26, 2016 23:13
@lukebakken lukebakken closed this Jan 26, 2016
@lukebakken
Copy link
Contributor Author

@javajolt @JeetKunDoug - I rebased on riak/2.0 and opened #982

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.

6 participants