[1.1.0] Fix deferred trx processing

[heifner]

Currently with #1027 a long running trx is interrupted when the oc compile completes. This causes an issue with deferred trx processing in old blocks where deferred trxs exist. Disable interrupt of transaction when oc compile completes for implicit transactions. Implicit transactions include deferred onerror and onblock. Not interrupting onblock seems like an ok thing here as onblock is part of the main system contract.

Also stop() timer on oc interrupt so start() is always called on a stopped timer.
Also call checktime() after setup of cleanup in eos-vm-oc so that set_expiration_callback(nullptr, nullptr); is called on checktime exception.

chicken-dance mismatch still on this branch which is being tracked by #1152

Resolves #1145

[spoonincode]

Can you describe a call path that yielded the failure a little more? Because,

Also call checktime() after setup of cleanup in eos-vm-oc so that set_expiration_callback(nullptr, nullptr); is called on checktime exception.

Couldn't this on its own have been a problem in prior releases?

[heifner]

Can you describe a call path that yielded the failure a little more? Because,

Also call checktime() after setup of cleanup in eos-vm-oc so that set_expiration_callback(nullptr, nullptr); is called on checktime exception.

Couldn't this on its own have been a problem in prior releases?

This has been this way since 2.0.0. I noticed it during visual inspection of all calls to set_expiration_callback. Certainly seems like this could have been an issue at any point. Maybe there was something that prevent(ed) checktime from ever being triggered there.

[spoonincode]

Sorry I should have written those as 2 separate questions more clearly. Can you describe the (or a) flow that was causing the problem?

[heifner]

Sorry I should have written those as 2 separate questions more clearly. Can you describe the (or a) flow that was causing the problem?

onerror case

While applying a block a deferred transaction is processed. During the processing of the deferred transaction the action was interrupted via oc interrupt. This throws the interrupt_oc_exception transaction out of apply (line 191):

spring/libraries/chain/include/eosio/chain/wasm_interface_private.hpp

Lines 185 to 195 in 845576c

	} catch (const interrupt_exception& e) {
	if (allow_oc_interrupt && eos_vm_oc_compile_interrupt && main_thread_timer.timer_state() == platform_timer::state_t::interrupted) {
	++eos_vm_oc_compile_interrupt_count;
	dlog("EOS VM OC compile complete interrupt of ${r} <= ${a}::${act} code ${h}, interrupt #${c}",
	("r", context.get_receiver())("a", context.get_action().account)
	("act", context.get_action().name)("h", code_hash)("c", eos_vm_oc_compile_interrupt_count));
	EOS_THROW(interrupt_oc_exception, "EOS VM OC compile complete interrupt of ${r} <= ${a}::${act} code ${h}, interrupt #${c}",
	("r", context.get_receiver())("a", context.get_action().account)
	("act", context.get_action().name)("h", code_hash)("c", eos_vm_oc_compile_interrupt_count));
	}
	throw;

This interrupt_oc_exception is expected to be caught in transaction_context:

spring/libraries/chain/transaction_context.cpp

Lines 371 to 375 in 845576c

	} catch ( const fc::exception& e ) {
	if (i == 0 && e.code() == interrupt_oc_exception::code_value) {
	reset();
	continue;
	}

However, onerror calls trx_context.execute_action directly from the controller:

spring/libraries/chain/controller.cpp

Line 2673 in 845576c

trx_context.execute_action( trx_context.schedule_action( trx.get_transaction().actions.back(), gtrx.sender, false, 0, 0 ), 0 );

Which means the interrupt_oc_exception would be caught here:

spring/libraries/chain/controller.cpp

Line 2693 in 845576c

} catch( const fc::exception& e ) {

This interrupt_oc_exception would cause the onerror to fail. But the failure is captured into a trace of the onerror (not thrown on out). This results in a hard_fail instead of a soft_fail. Also the trx_context is undone instead of squashed.

deferred trx case

I'm not really sure why interrupting deferred trxs exec() would be a problem. I was thinking it was because it created its own undo_session. But it shouldn't when validating a block. I now don't see why interrupting a deferred trx would cause any issue. I does, because one of the runs had the not interrupt for implicit but do interrupt for scheduled and that chicken-dance failed with an invalid soft_fail.

[heifner]

This was not needed. The undo() call above calls transaction_timer.stop(). I can remove it, but having it here makes it more obvious that it is being called.

[ericpassmore]

Note:start
category: Other
component: Internal
summary: Fix deferred trx process to support replay-ability.
Note:end