I tried recreating this today again and it doesn’t work.
The button process:
A button creates a PDF and stores it in a specific column
A rich text email is created and attaches the output of the specific column as a file attachment.
The PDF is created and the rich text email is sent but there is no attachment.
However, if I click the same button again and a second PDF is created in the file column, the email that is sent contains the PDF.
It appears that the email is being sent before the PDF is attached. The second attempt (with now 2 PDFs in the file column) contains an attachment because it is fetching the first file created and attaching it. I have done some tests and can confirm that it sends the previously created file and not the new one.
My workaround
I added some other actions between the creation of the PDF and the sending of the email in order to create a time buffer. One was to modify files in a row and the other was to send a notification. Both separate actions were necessary for the email to contain the attachment. Only using one of these actions did not provide enough buffer.
I am able to reproduce this bug. But it seems like this does not occur 100% of the time and is instead caused by a race condition.
I think I know what is happening (this is quite technical):
If you click a button inside the web UI, the defined actions are executed sequentially on the client side.
In other words, the API request to send the email is only sent by the browser after the API request to generate a PDF file from a page design template has finished (i.e. the file was successfully uploaded to the SeaTable server).
But the client-side code that triggers the email API request uses the information from the current row (i.e. the local state inside your browser) to determine whether attachments need to be sent alongside the email.
The timing here depends on the WebSocket message (about there being a new file inside a column) reaching the browser fast enough before the API request to send the email is executed.
@Leo.Shi Can you confirm my guess that this is the root cause?
If this is the case, wouldn’t it be better to resolve the current row on the server-side? Relying on the message reaching the client fast enough is rather brittle imo.
EDIT:
This supports my guess that this is caused by a race condition.
