InvokeTwice

[Ashuaidehao]

Relate #743

[shargon]

Won't this negate the use of GasLeft? Some projects might use the GasLeft method to either execute or not execute code, or simply to iterate.

[Ashuaidehao]

Won't this negate the use of GasLeft? Some projects might use the GasLeft method to either execute or not execute code, or simply to iterate.

It depends. It may happens even without this changes.

[roman-khimov]

If both invocations end up the same way, then why do we do the second one? If the result of two invocations is different, then which is the correct one and what should be returned to the user?

BTW, network fee can probably be roughly estimated (not precisely, but still).

[erikzhang]

If the result of two invocations is different, then which is the correct one and what should be returned to the user?

The second one is the correct one.

[roman-khimov]

If we suppose different execution results, then the second run can easily end up in FAULT state just because of insufficient GAS (gas: Engine.GasConsumed from the first invocation).

[erikzhang]

If we suppose different execution results, then the second run can easily end up in FAULT state just because of insufficient GAS

Why?

[roman-khimov]

If contract's logic depends on fees it might take some longer branch on the second execution, so the GAS amount from the first execution won't be enough. I'd suggest using gas: gas for the second one, but even that is not perfect of course. If Engine.GasConsumed will be different, then we don't know what's going to happen with the contract in a transaction with this new SystemFee.

I don't see any perfect solution to this, setting some semi-random value or using statistical data to set fees for executions is wrong as well. And code can always check Runtime.GasLeft to see that it has more (or less) GAS there than there is in the SystemFee.

[erikzhang]

If contract's logic depends on fees it might take some longer branch on the second execution

The idea is that if a contract's logic depends on fees, it checks if sys_fee is 0 to determine if it's currently a test execution.

[roman-khimov]

While that's the most likely scenario, it's not the only one that can happen. And zero vs non-zero fee can already lead to any kind of change between two invocations, including those that will require more GAS to finish successfully.

[vncoelho]

Looks go to me, I just need to test.

[roman-khimov]

So, what if it fails?

[vncoelho]

If it fails it will be a good change, because before it was HALT.
The flow looks like to be the same, @roman-khimov, nothing will change from the original flow, it just add a more precise gas limit

[roman-khimov]

If it fails it will be a good change, because before it was HALT.

But what's good about it? Estimation failed? How do I send a transaction then?

I know these things are not likely to happen, but contracts checking fees shouldn't exist as well and yet they do.

it just add a more precise gas limit

For normal contracts it changes nothing (except for additional execution overhead), for strange contracts that care about fee values it can lead to any result --- some will work, some will fail.

[vncoelho]

I think it can be merged.

Can you verify @superboyiii
@shargon, you have approved in the past, are you in agreement still?

[shargon]

I think that the project should use GasLeft, it's a very specific case that can be solved in this specific smart contract

[vncoelho]

So, @shargon, you mean make another change that set GasLeft as default?

[shargon]

So, @shargon, you mean make another change that set GasLeft as default?

As I understand it's a problem that can be solved by the smart contract

[vncoelho]

I think the problem here is more related to the simulation when we invoke RPC, no?

[Jim8y]

close as not planed and author agree to close