PDF Document Generation - PDF is generated faster than a database commit

0
I have a strange situation in my app, and I am wondering if it is a bug and if I can do anything to avoid it.The situation:In my microflow, I am updating an attribute in a submicroflow and commiting the object in the same sub microflow. In the next step (top microflow), I am generating a PDF using the "Generate PDF from page" action (Wair for result is set to true). The attibute I updated is displayed in an HTML element on this PDF. The PDF is saved as FileDocument and downloaded at a later stage by the User. I checked that the updated object is indeed passed to the PDF generator.The problem:The attribute value in the PDF is not the value I commited before generating the PDF. I set a default value for the attribute and the default is shown. It seems to completely ignore the commit (or bypass it).The strange thing is, if I generate and show the PDF in my browser (without saving it as Filedocument) using the exact same flows the attribute value is the value I commited.
asked
2 answers
2

This might not be a bug. As you may know, Mendix does not always flush all database commits immediately. Even if you call Commit in a sub-microflow, the transaction is still part of the main microflow and may not yet be fully finalized at the database level. It sends all objects that will be committed with End Activity in the mail microflow. 


The PDF Generator works differently because it renders the page in a separate context (headless browser). If the transaction has not been fully completed yet, the PDF generation may read the previous state of the object instead of the updated value.


To verify this, you can try calling the EndTransaction action from the CommunityCommons module just before generating the PDF. This forces the current transaction to complete and ensures that all committed values are available to the PDF Generator.


If the PDF shows the correct value after using EndTransaction, it confirms that the issue is related to transaction timing rather than a commit failure.


answered
0

Check whether the user who is committing the modified file has given proper access rights for read/write

answered