Surface webpack cache generation errors in build output

[frankmueller-msft]

Summary

• Changes WebpackTask.getDoneFileContent() to throw on error instead of silently returning undefined
• The thrown error propagates to markExecDone()'s existing catch block, which prints one warning that includes the actual error message (e.g., the missing module or config parse failure)
• Before: "warning: unable to generate content for /path/to/done.log" (no root cause)
• After: "warning: unable to write /path/to/done.log\n error: failed to generate incremental build cache for webpack.config.cjs: Cannot find module '...'" (actionable)

Contract change

The original code caught errors and returned undefined, treating failure as "no content available." This changes it to throw, treating failure as an error condition. Both current call sites (markExecDone and checkLeafIsUpToDate) have try/catch blocks that handle thrown errors correctly, so behavior is preserved. However, getDoneFileContent()'s return type is Promise<string | undefined>, which signals that undefined is a valid return. Future callers should be aware that WebpackTask's override may throw instead.

Test plan

• Build - build-tools pipeline passes (build + policy checks)
• repo-policy-check passes

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR makes fluid-build webpack incremental-cache failures actionable by surfacing the underlying exception in normal build output (not only behind DEBUG=fluid-build:task:error), helping engineers diagnose why done-file content generation failed.

Changes:

• Updates WebpackTask.getDoneFileContent() error handling to include clearer trace text.
• Emits a console.warn with the package name, config path, and the underlying error message when done-file content generation fails.

[alexvy86]

Generally I think I agree with the direction (I think surfacing the errors is valuable) but with a couple of caveats:

• In the codepath for markExecDone the message in the warning will be misleading; right now it would log ... unable to generate content for ... and with this change it would say ... warning: unable to write ... which arguably was intended to point to errors thrown by await writeFile(doneFileFullPath, content); in leafTask's markExecDone, but now would point readers to the wrong root cause.
• Same thing in checkLeafIsUpToDate inside LeafWithDoneFileTask. Current message is "unable to generate done file expected content (getDoneFileContent returned undefined)", and with the new behavior it would change to "unable to read compare file: ..." which seems to correspond to a failure in a call after getDoneFileContent is called and returns a non-undefined result.

Personally I wouldn't object strongly to updating the error messages in the new places that would be logging the error, so they more accurately reflect what could have gone wrong. But I'd also check with @tylerbutler about the general architecture of this part of build-tools, in case he was involved with this part.

[frankmueller-msft]

Good catches @alexvy86 — you're right that both messages were misleading. I've pushed a fix:

• markExecDone catch: "unable to write ..." → "unable to generate or write done file ..."
• checkLeafIsUpToDate catch: "unable to read compare file: ..." → "unable to generate or read compare file: ..."

Both catch blocks can now be entered from either getDoneFileContent() throwing or the subsequent I/O operation failing, so the messages reflect both failure modes.