Create Text Attachment Issue

I am running into some strange issues that I’m having trouble debugging. Outline of the process:

  1. I have a custom HTML component that users interact with which results in modifications to the HTML that are saved back into an object in the database
  2. Users click a finalize button that locks in their edits
  3. User clicks a submit button that: (1) retrieves the HTML from the component, (2) saves that HTML into a file, and (3) saves that file onto the object triggering a cloudcode task to submit the file into an external system via REST API

(3) is where I’m running into issues. The file is stuck at (not uploaded yet) when I check the database:


There’s logic in the cloudcode task that retries if file is not ready, but it just endlessly retries and the file never finishes. I’ve waited >10 minutes. There are a couple ~50 KB photos base64 encoded into the HTML but it shouldn’t be any more than 200 KB. Here’s an abbreviated code sample:

var html = component.html({ id: htmlId }).post('get-html');
view.object.file_data = Attachment.create({text: html, filename: 'data.html'});
// Triggers the cloudcode task
view.object.do_submit = true;;

Edit: file_data is of course an Attachment field:

Any ideas? Suggested improvements?

Maybe the problem is that you cannot store .html files? Try storing it as .txt instead to see if it at least creates the attachment as expected.

I should have updated my post, but I did already rule that out. Changing the filename to data.txt yields identical behavior. My submission from yesterday afternoon ~18 hours ago is still sitting at “(not uploaded yet)”

Interestingly, the audit history shows that the Attachment did upload. Is it possible that the update in the cloudcode task immediately following that event interfered with finishing the Attachment upload?

I’ll test that out. I.e. refactor the cloudcode to not save any changes to the object in the case that the task has been rescheduled.

Edit: Nope, that did not work. Same logs just without the cloudcode update:

Update for others that may hit this issue: I worked through this with support and there is some validation in the cloud database that prevents storage of html attachments presumably for security reasons. As a workaround, I’ve replaced all < characters with another arbitrary character so that the cloud no longer detects it as html. Then on the receiving end, I’ve set up logic to change them all back after downloading the file.

Another valid solution might be to compress into a ZIP or similar, but I went the simple albeit perhaps messier route.

Other candidate solutions apart from compress to ZIP could be:

  1. Use an html escape lib [example], or
  2. Use base64