AppExit should be an observer event rather than a BufferedEvent #20408

[martinfrances107]

Objective

Performance:

• Replace logic that run every frame, by using the observer pattern.
• Less event buffering so smaller memory footprint at runtime.
• Fixes AppExit should be an observer event rather than a BufferedEvent #20408

Solution

• A new Resource is added which stores the first error event seen.
• Now using command.trigger to generate Events.
• Examples updated.

This is low level plumbing, no many public interfaces have been adjusted.

Testing

• Existing tests have been modified, No additional tests.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[martinfrances107]

In terms of reivew, should I be using a Resource to store the first error observed?

I will rapidly reponse with changes to PR is there is a more natural alternative

[alice-i-cecile]

I don't have time to review / debate this now, but this needs careful consideration as it has implications for large-scale patterns in Bevy's code.

The other reason I think this is controversial is that the lack of observer ordering is felt particularly acutely with AppExit, and needs to be carefully considered.

[martinfrances107]

I still need to debug this...

I am new to the project, so I fully expect my reasoning needs correcting

We are swapping A for B where

A ) Buffered Events for where the order of events is preseved

for

B) Commands pushed onto the command queue, which is determinsitc.
( At least command 1 is executed before command 2 etc. )

The function in question is to latch the first error observed.

Is there a race condiction here .. where Resources are maybe delayed in their update such that a stale resource is read twice leading to the second or third error being latched?

As I say I am not telling, I am learning?