Load scene order, awake and start

I post this here because I'm us ing 2019.3 beta in this project, but I'm not sure it is 2019.3 related. I'm loading a scene in additive mode and removing extra gameobjects in the new scene during Awake call (simple Singleton). But as seen in this picture, everything seems to happen in the same frame (frame number just after printed time): destroying the object (done in parent root Awake call, executed before any other script), child Awake and child Start call ??

Start is called the next frame after Awake (basic, it would be redundant otherwise) so I can't understand this error. It is caused - my guess - when the parent object (canvas) has been destroyed but the child script is trying to get its canvas component.

 

Is this a beta issue? This seems like what I'd expect, and doesn't seem like a bug to me. I've noticed that Awake and Start seem to be one frame apart, when awake is called on the first frame. But later on, I don't think there's any expectation that Awake and Start will be separated by a frame. It's just that Awake will be called before Start is call, but they could both occur on the same frame.

Calling Start on the same frame as Awake wouldn't be redundant. They're different kinds of operations. Awake contains code that should generally be isolated to the component itself, while Start could contain code that assumes other components exist in the scene.

 

Well, I didn't mean it was a bug, I started this topic by assuming this could be a missunderstanding. Regarding Start and Awake called at the same frame, I see your point. I expected them to be in a different frame, but I don't really care as long as Awake is completed before Start. In this example, I destroyed the parent object in Awake, but destruction is not immediate, it happens later in the frame (Unity docs). But I did expected that this object and their children wouldn't run Start, they should be destroyed before any Start(). Unless there is something more going on that I can't see, and I have been looking at it for a while, this is not really what I would expect.

I'm using a custom flag to make sure the object was destroyed to carry on, but imo it should not be necessary.

 

Unity doesn't destroy things immediately. There is a delay between when your C# code tells an object to be destroyed and when the internal C++ code actually destroys it. But Unity lies to you and tells you the object is destroyed or null in that interim.

So yes, this is confusing, but I think it's expected behavior.