Improve ChunkLoadError message for loaded chunks

[muskaan1212]

Summary

This PR improves the ChunkLoadError message for cases where the script load event fires, but the chunk is still not registered as loaded.

Previously, webpack reported this case as missing, which can be misleading because the chunk script may have loaded successfully but failed during parsing, evaluation, or execution. This change updates the message to loaded but not executed to make the failure reason easier to understand while debugging.

Related to #16618

What kind of change does this PR introduce?

fix

Did you add tests for your changes?

No tests have been added yet. This is a small runtime error-message improvement, and I would appreciate maintainer guidance on the preferred test location or whether an existing runtime test should be updated.

Does this PR introduce a breaking change?

No. This only changes the wording of the ChunkLoadError type/message for this specific load-event case.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

No documentation changes are required at this time.

Use of AI

I used AI assistance for learning support while understanding the issue discussion and navigating the webpack codebase. I manually reviewed the relevant file, made the code change myself, checked the diff, and verified it with git diff --check before submission. AI was not used to generate unreviewed code.

[changeset-bot]

⚠️ No Changeset found

Latest commit: a428f0e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: muskaan1212 / name: muskaan1212 (a428f0e)

[github-actions]

👋 Hi there! This PR was automatically flagged and closed by our quality checks.

If you believe this was a mistake, please review our contributing guidelines
and leave a comment explaining why this is a mistake.

[muskaan1212]

Hi maintainers, thanks for the automated checks.

I noticed this PR was closed because my CLA was not signed and possibly due to quality/AI policy checks. I will complete the CLA authorization first.

For context, my intention with this PR was to make the ChunkLoadError message less misleading when the script load event fires but the chunk is still not registered. I understand that the issue may require a deeper solution, such as exposing the original runtime/parsing error, and I’m happy to revise the approach or add tests if maintainers think this direction is useful.

Could you please let me know whether this wording-only change is acceptable after CLA completion, or whether I should instead investigate a way to preserve/report the original error?

[muskaan1212]

Hi maintainers, I have completed the CLA process.

I understand the PR was automatically closed by quality checks. I’ve also clarified the AI usage section to explain that AI was used only for learning/navigation support, and that I manually reviewed the code change and verified the diff before submission.

Could you please let me know if this PR can be reopened, or if you would prefer that I investigate a deeper approach for #16618, such as preserving/reporting the original runtime or parsing error instead of only changing the wording?

[muskaan1212]

Hi maintainers, I have completed the CLA process.

I understand the PR was automatically closed by quality checks. I’ve also clarified the AI usage section to explain that AI was used only for learning/navigation support, and that I manually reviewed the code change and verified the diff before submission.

Could you please let me know if this PR can be reopened, or if you would prefer that I investigate a deeper approach for #16618, such as preserving/reporting the original runtime or parsing error instead of only changing the wording?