- Newest
- Most votes
- Most comments
Seems you figured it out. It works now when I tested via validate-template as well as direct upload. :)
Okay, I found it. My stack files were being built by the Python library troposphere and written to disk via pipe, and SOMEWHERE in that chain of great decisions the files were being written in UTF-16 encoding, which explains all of this behavior -- CloudFormation is unable to parse the file, and Designer correctly shows the bloat of incomprehensible two-byte characters (which is why everything was spaced out funny in the parse screenshot) but when the file is directly uploaded into Designer, Designer is smart enough to transcode the file back into UTF-8 and export something CloudFormation could accept.
To me this is a clear CloudFormation bug -- if it doesn't like the encoding it should be detecting and rejecting it on those terms, because the only reason I figured this out is because I spotted VSCode mention UTF16 when I was uselessly toggling the CRLF encoding.
Thanks!
Hello, Ev.
I appreciate you checking! Unfortunately, I didn't change anything and after testing just now I'm still seeing the same behavior -- on two otherwise-unconnected AWS accounts, no less. As soon as I hit the orange "Next" button I slap right back to the same screen with a red banner announcing "Template contains invalid characters", and selecting "View in Designer" gives the same deranged parse I quoted in the screenshot.
Is there anything I can provide to help narrow this issue down?
Just to let you know, I had another user test and verify this issue as well -- that's two people, four accounts, that have uniformly shown this behavior. Is there a CR/LF thing that Designer doesn't get tripped up by but straight import does, maybe?