No way to resolve the replication conflict of the operation type is 'insert.'

[Kasen]

Tarantool version:
1.10.3-80

OS version:
MacOS 10.14.6

Bug description:
I try to resolve the replication conflict between two tuples with before_replace trigger. Which looks like this:

function(old, new)
    -- the fourth field is a timestamp
    if new and old and box.session.type() == 'applier' and new[4] > old[4] then
        return new
    end
end

If an operation type is 'replace' then this trigger works correct, but if an operation type is 'insert', I receive the error:

 error applying row: {type: 'INSERT', replica_id: 1, lsn: 6, space_id: 512, index_id: 0, tuple: [12477, '1837192990', '0002', 1568389264.6109, 1, 1, 3, '']}

So I don't know how to resolve this conflict. 🤷‍♂

Steps to reproduce:
On master instance:

1. box.schema.create_space('t')
2. box.space.t:create_index('primary')

On replica instance:

1. box.space.t:insert({1})
2. box.space.t:before_replace(function(old, new) return new end)

On master instance:

1. box.space.t:insert({1})

[Gerold103]

That is correct. You can't. The primary key stays the same, and the operation type is still INSERT after your trigger, and the old tuple still exists. So there is no reason why this INSERT should not fail.

[Gerold103]

But. You can change the new tuple, and it will turn the operation into REPLACE. Try this:

box.space.t:before_replace(function(old, new) return box.tuple.new(new) end)

[Gerold103]

Sorry, closed accidentally.

[kostja]

Given there is a workaround, this should be turned into a documentation issue.

[printercu]

What if changing INSERT into REPLACE is not acceptable? Ex., I want to skip only duplicate records but still get an error for any other conflicts like this:

    space:before_replace(function(old, new)
        if old and new and utils.tuples_equal(old, new) then
            return old
        end
        return new
    end)

UPD. It appears that this code works as intended, and the problem was in the inserted data.

[kostja]

OK, so what is the issue then? You can return old, new, or an entirely new tuple - the trigger may behave differently depending on data it receives.

For this and many other cases we need to add access to transaction state through Lua API. It's a matter of adding a few Lua bindings, so is more like a feature, not a bug. But given it's pretty safe to add these bindings, I think we can add them to 1.10 as well.

The bindings should provide access not only to the current operation type, but LSN and server id.