An EVM Call (contract view function call) can use the Cadence arch function, the problem is, because we don't have the complete Flow environment setup locally we can not produce the results for those methods. One example is: we have a generate secure revertible random cadence arch function, because EVM GW doesn't have access to the random beacon we can not produce those results locally. So the call will fail.
This problem was solved for transactions in a way that during the transaction execution on EN, the input/output produced by this call is recorded and then added to the EVM transaction executed event, and locally on the EVM GW when we re-execute that transaction we mock the call to the cadence arch because we know the output it should produce. The problem with calls is that we don't execute them on EN by default, so we can't know what the cadence arch should return when we re-execute them locally.
One solution is to make sure all the failed calls have fallback to being executed on EN, so in that case we would still produce the correct result which would be returned to the client, while still offloading the EN with all successful calls.
This could be further improved by detecting the reason the call failed, and if that reason is that it failed to call cadence arch function we would fall back to EN. I think this is not worth optimization at this point unless proven different with metrics. Both failed calls and especially cadence arch calls are a minority of requests.
An EVM Call (contract view function call) can use the Cadence arch function, the problem is, because we don't have the complete Flow environment setup locally we can not produce the results for those methods. One example is: we have a generate secure revertible random cadence arch function, because EVM GW doesn't have access to the random beacon we can not produce those results locally. So the call will fail. This problem was solved for transactions in a way that during the transaction execution on EN, the input/output produced by this call is recorded and then added to the EVM transaction executed event, and locally on the EVM GW when we re-execute that transaction we mock the call to the cadence arch because we know the output it should produce. The problem with calls is that we don't execute them on EN by default, so we can't know what the cadence arch should return when we re-execute them locally.
One solution is to make sure all the failed calls have fallback to being executed on EN, so in that case we would still produce the correct result which would be returned to the client, while still offloading the EN with all successful calls.
This could be further improved by detecting the reason the call failed, and if that reason is that it failed to call cadence arch function we would fall back to EN. I think this is not worth optimization at this point unless proven different with metrics. Both failed calls and especially cadence arch calls are a minority of requests.