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

Mas i1677 head #1710

Merged
merged 7 commits into from
Sep 2, 2019
Merged

Mas i1677 head #1710

merged 7 commits into from
Sep 2, 2019

Conversation

martinsumner
Copy link
Contributor

@martinsumner martinsumner commented Aug 23, 2019

As part of the investigation into the implementation of a genuine HEAD API to Riak, the current GET code and its use of HEADs was reviewed. The outcome of this review was:

  • The code was hard to follow and lacking in both comments and dialyzer specs;
  • The code was lazy, it would give sub-optimal answers in some cases because the extra fetch workload was probably not a problem. However, this variance increases the scope for there to be incorrect behaviour that is not detected by system tests.

This PR adds comments and specs. It also refactors the code in attempt to both improve readability and consistency of behaviour. The unit tests have then been expanded to reflect this.

The change also removes an is_x_deleted check, as deleted tombstones (even when fetched by HEAD requests) should already not require fetching as they have already been converted into actual objects (not just HEAD objects) - https://github.com/basho/riak_kv/blob/riak_kv-2.9.0p4/src/riak_kv_get_core.erl#L109-L119.

Adding further unit tests demonstrated some non-determinism in the find_bestobject/1 function in that it might consider different answers to be siblings depending on the order the answers would be received.  That is to say dominated siblings may or may not be included.

It would be better to make this predictable, so that any riak_test that proves behaviour with siblings can't be dependent on the order of answers - increasing confidence that such situations are handled correctly
When a head is a tombstone, the get_core will convert it into something object like (using riak_object:spoof_deletedobject/1), when the response is added to the get_core.  Hence we don't need to consider when running find_bestobject that head objects could be deleted.

There had previously been logic in merge_heads to discount tombstone head responses as things that need to eb fetched - but they shouldn't be head-like things at that stage due to the use of spoof_deletedobjects.  This logic is therefore superfluous.

Also contains a check that the riak_kv_util:is_x_deleted/1 function does work as expected on HEAD-like responses.
merge_heads if it returns {fetch, IdxList} should be a list of partition IDs not of results.

Added a spec to the function to try and avoid this mistake being repeated.
@martinsumner
Copy link
Contributor Author

This has been run through a standard volume test, as well as riak_test tests, as well as the extended unit tests.

Without the fix the extended unit tests fail. This is not obviously critical, however, it would be safer and more reliable to have the fixes in place

@yorkshire-steve
Copy link

+1 from me. Code reviewed and discussed with Martin. Agreed including this fix in next 2.9.0 patch is appropriate.

@martinsumner martinsumner merged commit 1620b00 into basho:develop-2.9 Sep 2, 2019
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.

2 participants