Investigate why the delay is necessary instead of relying on arbitrary timing.

Adding a 100ms delay before app.close() suggests a race condition where app.ready() resolves before all boot lifecycle events have fully completed. This approach has several concerns:

• The delay is arbitrary and may be insufficient on slower systems or in CI environments
• It doesn't address the root cause of why app.ready() doesn't guarantee readiness
• Time-based delays make tests brittle and slower

Consider:

1. Adding a comment explaining what specific asynchronous operation needs to complete
2. Waiting for a specific event or condition instead of a fixed delay
3. Investigating whether the boot lifecycle should ensure all operations complete before ready() resolves

Run the following script to check if there are any pending async operations after app.ready():

Also applies to: 57-57

🏁 Script executed:

#!/bin/bash
# Description: Search for setTimeout, setImmediate, or process.nextTick in boot-related code
# that might explain why additional delay is needed

rg -n -C3 'setTimeout|setImmediate|process\.nextTick' --type ts -g '**/boot*.ts' -g '**/loader*.ts'

# Look for the boot app fixtures to understand their lifecycle
fd -t f "app.ts|app.js" -p "boot-app"

Length of output: 95

🏁 Script executed:

#!/bin/bash
# Locate scheduler implementation files
fd -t f scheduler*.ts

# Display the first 200 lines of each scheduler definition
for f in $(fd -t f scheduler*.ts); do
  echo "==> $f <=="
  sed -n '1,200p' "$f"
done

# Show usage of scheduler in the load_boot test file
rg -n "scheduler" -C3 packages/egg/test/lib/core/loader/load_boot.test.ts

Length of output: 6726

🏁 Script executed:

#!/bin/bash
# Locate all utils.ts files
fd -t f utils.ts

# Display contents to find createApp and MockApplication definitions
for f in $(fd -t f utils.ts); do
  echo "==> $f <=="
  sed -n '1,200p' "$f"
done

Length of output: 26197