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

Delete operation on primary don't do version handling correctly, on 5.3 & 5.x #23069

Closed
bleskes opened this issue Feb 9, 2017 · 2 comments
Closed

Comments

@bleskes
Copy link
Contributor

bleskes commented Feb 9, 2017

I believe this has happened during the back port of #21964 and only relates to the yet to be released 5.3.0

Here's the logic of the delete operation (it's the same both on master and 5.x):

    public static Engine.DeleteResult executeDeleteRequestOnPrimary(DeleteRequest request, IndexShard primary) throws IOException {
        final Engine.Delete delete = primary.prepareDeleteOnPrimary(request.type(), request.id(), request.version(), request.versionType());
        return primary.delete(delete);
    }

Notice how it doesn't do any version conversion for replicas.

On master, this is done in TransportShardBulkAction#executeBulkItemRequest:

case DELETE:
    final DeleteRequest deleteRequest = (DeleteRequest) itemRequest;
    Engine.DeleteResult deleteResult = executeDeleteRequestOnPrimary(deleteRequest, primary);
    if (deleteResult.hasFailure()) {
        response = null;
    } else {
        // update the request with the version so it will go to the replicas
        deleteRequest.versionType(deleteRequest.versionType().versionTypeForReplicationAndRecovery());
        deleteRequest.version(deleteResult.getVersion());
        deleteRequest.setSeqNo(deleteResult.getSeqNo());
        assert deleteRequest.versionType().validateVersionForWrites(deleteRequest.version());
        response = new DeleteResponse(request.shardId(), deleteRequest.type(), deleteRequest.id(), deleteResult.getSeqNo(),
            deleteResult.getVersion(), deleteResult.isFound());
    }

5.x doesn't have that logic in the same method, but rather relies on handling in the execute*OnPrimary method. Here is the relevant code from the index variant:

        if (result.hasFailure() == false) {
            // update the version on request so it will happen on the replicas
            final long version = result.getVersion();
            request.version(version);
            request.versionType(request.versionType().versionTypeForReplicationAndRecovery());
            assert request.versionType().validateVersionForWrites(request.version());
        }

We need to go through the backport again and make 5.x do what master does.

PS. This is yet another proof unit tests are badly needed for this. @dakrone has already started working on it.
PPS. Areek is working on making this entire thing less messy.

areek added a commit to areek/elasticsearch that referenced this issue Feb 9, 2017
As @bleskes pointed out in elastic#23069 there were inconsistencies
in version handling on 5.x and 5.3 from master due to backport
of elastic#21964. This change ensures versions are handled uniformly
and fixes minor issues in shard bulk action to be similar to master

fixes elastic#23069
areek added a commit that referenced this issue Feb 9, 2017
As @bleskes pointed out in #23069 there were inconsistencies
in version handling on 5.x and 5.3 from master due to backport
of #21964. This change ensures versions are handled uniformly
and fixes minor issues in shard bulk action to be similar to master

fixes #23069
areek added a commit that referenced this issue Feb 9, 2017
As @bleskes pointed out in #23069 there were inconsistencies
in version handling on 5.x and 5.3 from master due to backport
of #21964. This change ensures versions are handled uniformly
and fixes minor issues in shard bulk action to be similar to master

fixes #23069
@dakrone
Copy link
Member

dakrone commented Feb 9, 2017

@areek I think this is closed by your PR? unless we want to keep it open until we have unit tests?

@bleskes
Copy link
Contributor Author

bleskes commented Feb 10, 2017

Fixed by #23083

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

No branches or pull requests

3 participants