I don't think it gets to invoke the child frame because in the case of e.g. invalid init contract code, an empty item would be put on the operand stack signaling failure and not a new frame. Another example would be if the code is too large a halt state would be returned back. So there's some validation of the code before the child frame gets to execute from what I see, which would fall into your criteria I believe?

The child frame is only spawned here and then we re-enter the process cycle again to run the init code and TraceContextEnter gets called.

Thanks @lu-pinto. WRT The code size issue

if (code != null && code.getSize() > maxInitcodeSize) { ... }

maxInitcodeSize limitations apply on later releases than London (IIRC it's twice as much as the maximum deployed bytecode size of 24576). Our arithmetization targets the London EVM.

invalid init contract code

What do you mean by that ?

Also for info: everything in Linea is done with respect to the London EVM. So any EIP's beyond London don't apply.

This snippet of code you point to preceding the nonce update

    if (value.compareTo(account.getBalance()) > 0
        || frame.getDepth() >= 1024
        || account.getNonce() == -1
        || code == null
        || code.getEofVersion() != frame.getCode().getEofVersion()) {
      fail(frame);
    }

relates to what the issue calls aborted CREATE's. In the present issue we are concerned with what we have called CREATE's raising a failure condition.

And the link you provide suggests that CREATE's that aren't aborted (and may therefore still raise a failure condition) actually spawn a child context.

Sidenote (for myself) I recognize either

        || account.getNonce() == -1

@letypequividelespoubelles pointed out that the nonce restriction is likely related to java's Long.MAX_VALUE and some EIP about the max value of nonces being 2**64 - 1.

This condition is I guess some Besu stuff.

        || code == null

Note. We are not enforcing the nonce to be a uint64 ... This may lead to some reference tests breaking.

Our arithmetization targets the London EVM.

I see... I don't remember hearing that until now. I'll have another look keeping that in mind.

maxInitcodeSize limitations apply on later releases than London

Maybe I'm missing something but I don't see that this check is configurable through any settings specifically to the London hardfork. Currently the besu code that Linea is running on is built on a fairly recent version of the besu client. delivery-26 is built from backport of besu@529bd33 git hash. Maybe the condition doesn't trigger with a london genesis file but it's not explicitly apparent that is the case.

I had another thorough look at unit tests that seem to confirm what I mentioned for maxInitcodeSize -> the check is done even for London EVMs. However the configuration is set to Integer.MAX_VALUE which is a large enough value that this check can be neglected. See london configuration here.

Regarding the invalid init contract code case, when code is loaded before execution, you are right that only EVMs with EOF V1 spec are impacted (not london). There is only a tiny case when maxEofVersion (CodeFactory.java) but that is a developer error which shouldn't happen since it's defined in EvmSpecVersion also.

Regarding:

Preliminary Conclusion. The link you provide suggests that CREATE's that aren't aborted (and may therefore still raise a failure condition) actually spawn a child context.

I don't see anything else other than the contract account validation after loading the child frame on the stack, inside ContractCreationProcessor.start(). At this point we have already entered the context for the child frame, so your conclusion is correct.
The contract account is checked if it already exists here. Is this the createe you were looking for @OlivierBBB? I'm guessing createe is the contract address being created by the sender. One other condition where we would fail is if the contract account storage is also not empty.