Custom Post-Generation Workflow Prevents UI Completion Notification

When using a custom post-generation workflow in AEM Guides Cloud, the UI notification becomes stuck on "In Progress - Generating <output>..." indefinitely. In my case, I was using a Native PDF output preset. Even though the success message "hangs," and the PDF is generated successfully, and the workflow completes without errors.

I'm using AEM Guides as part of the cloud service.

Symptoms

1. PDF generation completes successfully
2. Custom workflow executes and completes (verified in logs)
3. FinalizePostPublish step runs successfully
4. PDF file is created in /content/dam/fmdita-outputs/pdfs/
5. BUT: UI notification stays stuck on "In Progress..." forever
6. No success notification or download link appears

Root Cause Analysis

After investigation, I discovered that the output history node shows two different status properties:

Location of output history: /var/dxml/metadata/outputHistory/ <id> / <id> 

With Custom Workflow:

cloudStatus: "Finished" outputStatus: "Post-Publishing" <-- Never updates to Finished 

Without Custom Workflow (default behavior):

cloudStatus: "Finished" outputStatus: "Finished" <-- Updates to Finished

The Issue:
My logic is, the AEM Guides UI must poll the outputStatus property (not cloudStatus) to determine when to show the completion notification. When using a custom post-generation workflow, the FinalizePostPublish step sets cloudStatus but does NOT set outputStatus to "Finished", leaving it stuck at "Post-Publishing".

Workflow Structure That Fails

START → Custom Step → FinalizePostPublish → END

Note: for both steps "Handle Advance" is checks

My workaround

START → Custom Step(s) → FinalizePostPublish → Step to manually the Set Output Status to Finished → END

Using something like this, in another workflow step after the Finalize post gen workflow step:  props.put("outputStatus", "Finished"); 

Questions

1. Is this the intended behavior for custom post-generation workflows?
2. Should FinalizePostPublish be updated to set both status properties consistently?
3. Can the documentation be updated to include this requirement?