Converting from Legacy Editor - Images changing to "Unknown Attachment" intermittantly

[Fraser Shepherd]

We've started converting our Confluence pages from the Legacy Editor to the new editor, we've noticed some weird behaviour on some of our pages.

On conversion, in-line/pasted images are changing to "Unknown Attachment", but not all the time or for every document, and not even all the time for the SAME document.

As an example : 

Page A has 5 in-line images pasted in at various points in the document.  These are pasted in as plain images, no third party apps or macros or anything that could cause compatibility issues.  Page A was created with the Legacy Editor, has 10 total Historic Versions, and when we hit "Edit" we are prompted to convert to the page away from the Legacy Editor.

On hitting "Convert Page" the in line images all change to "Unknown Attachment" and do not display any more.

Now the weirdness.

I revert back to Version 10, the last version before conversion, and the images reappear.  I then hit Edit AGAIN, allow the conversion to take place, and THIS time the images are retained.

This doesn't always work on the first try, or the second, but it does always EVENTUALLY work.  We've not found a page yet where "trying again a few times" doesn't work.  But we don't want to tell our users to "just keep trying till it works" for converting hundreds of pages, and this would remove any automation we might want to put in place for this conversion, as every page will need to be manually checked to ensure this issue has not occurred.

Any idea what could be going on here?  Is this a known bug/issue I'm overlooking?

[Alex Koxaras -Relational-]

Hi @Fraser Shepherd and welcome to the community,

Strange behavior, to say the least. Can you try copying the page and convert it again, and see if the problem persists? If the problem persists, can you check the page storage for anything suspicious? Another idea would be to export the page and try to import it again. Finally, if you are on a paid plan, raise a request to Atlassian's support.

Let me know if any of the above helps.

[Fraser Shepherd]

Hi,

Got a request open at the moment, just figured I'd ask the community while waiting in case there was some known nuance/issue I was unaware of.

I will try the above for a few pages, but again even if this does work I really don't fancy doing that for every page we need to convert :)

Thanks

[Alex Koxaras -Relational-]

Sure thing! Try it just for a couple of pages. If you have many pages of that type then it depends on what the problem is. E.g. if the problem would be located to a special character on each image, then you could use python to find these pages and then replace that character on their storage. That would solve the problem. Another option would be to have Atlassian do that (if applicable) :) 

[Fraser Shepherd]

I don't see anything particularly egregious in the code for the image when viewing storage : 

<ac:image ac:align="left" ac:layout="align-start" ac:original-height="222" ac:original-width="795" ac:custom-width="true" ac:width="795"><ri:attachment ri:filename="image2023-8-4_13-53-36.png" ri:version-at-save="1" /></ac:image>

[Fraser Shepherd]

Thats one of the "Correctly Converted" images.  Grabbing the code from a legacy page gives me similar : 

<ac:image ac:height="250"><ri:attachment ri:filename="image2023-8-4_14-28-37.png" /></ac:image>

[Alex Koxaras -Relational-]

I don't see anything suspicious as well. Did you try to export it and import it again an/or copy it to another space or page?

[Fraser Shepherd]

I will try with a different page.  The main issue is it does eventually always work, it just seems like <sometimes> the conversion fails.  Reverting to a prior version of the document and trying again fixes it.  So the conversion does work, it just seems to sometimes fail.  

I guess I'll just need to see if support see anything in the server logs maybe?

[John D Patton]

Hi Fraser,

You and Alex are on exactly the right track. This behavior—where it fails intermittently but then works on a retry—screams server-side timing or caching issue during the conversion, not a problem with your page content itself.

Since you already have a support ticket open (which is the only way this will get truly fixed), the most helpful thing you can do now is give the support engineers the exact data they need to find the error in their logs.

My suggestion:

The next time the conversion fails and you see the "Unknown Attachment" errors:

1. Do NOT revert the page yet.

2. While the page is in its broken state, copy the Page ID from the browser's URL (it's the long number).

3. Note the exact time (including your timezone).

4. Update your support ticket with a message like: "The conversion for Page ID [paste Page ID here] just failed at [paste exact time and timezone]. Please check the backend logs for this specific page and timestamp to find the error."

This gives them the "needle in a haystack" they need to isolate an intermittent bug. Just saying "it fails sometimes" is hard to debug, but "it failed for this page at this exact second" is something they can act on. This is probably the fastest way to get your issue escalated and resolved.

[Alex Koxaras -Relational-]

That seems like a good idea!

[Joseph L Whited]

Not sure if this is the same issue, but I had a similar problem when using api to post content to confluence from a script. Here's the write up we made about it:

Reproducible cause: pages created via the REST API in storage format are treated as legacy content unless you explicitly set the "editor" content property to v2.
Opening such a page in the Cloud editor converts it, and that conversion rewrites every attachment reference to UNKNOWN_ATTACHMENT - images and attached PDFs stop rendering.

Matched-pair test on Confluence Cloud, two pages created by the same script, identical body and identical two image attachments.
The only difference was the editor property.

- Page A - no editor property, which is the default for REST-created pages. Opened in the editor, the images immediately displayed as broken. The stored body was still intact at that point, so merely opening the editor does no permanent damage. On save, both refs were written to storage as ri:filename="UNKNOWN_ATTACHMENT", permanently.
- Page B - POST /rest/api/content/<id>/property with {"key":"editor","value":"v2"} right after creation. Same edit and same save, both refs intact, and the storage format was not rewritten.

Two details that cost us time:

- Passing metadata.properties.editor in the CREATE payload is silently ignored. The property reads back 404 afterwards. It has to be POSTed to /content/<id>/property as a separate call.
- The published Atlassian KB for "Unknown Attachment" attributes it to cross-page refs from copy/pasting images between pages. That is a different cause. Our affected pages had zero <ri:page> refs, and the refs were plain ri:filename on the same page.

Retrofitting the property onto existing pages is non-destructive.
It adds a property, does not change content, and creates no new version.
That protects pages already published by a script before anyone opens one in the editor.