[confluenceUnsupportedBlock] error caused by new Confluence editor

We’ve had a report from one of our customers that our dynamic content macros stopped working recently, showing the message [confluenceUnsupportedBlock] instead of rendering correctly.

The customer indicated that the same problem had started occurring with a number of macros (not only ours).

Initially we were unable to reproduce the error that the customer was reporting, but later we discovered that the customer was one of the initial instances to have received the new Confluence editor.

Once we learned this, we were able to reproduce the problem ourselves by creating a new blog post in one of our test instances (90% of all cloud instances now use the new editor for blog posts).

In our case, the affected macros are bodyType: plain-text.

The developer blog post for the new editor mentions changes required to bodiless (bodyType: none) and rich text (bodyType: rich-text) macros to support the new editor, but says nothing about plain text macros.

Are there any known workarounds for this?

There are a number of CONFCLOUD tickets open on JAC relating to issues with the new editor, so it could be a genuine bug in the editor (in which case we sincerely hope that Atlassian have suspended any further rollouts, as this has the potential to cause widespread issues).

We continue to receive reports from our customers who have been upgraded to the new Confluence editor and are affected by this issue.

Although we are advising our customers that the issue is entirely out of our control, the damage it is causing to our reputation is significant.

We try to be as transparent as possible with our customers, so our status page reports that our apps have been in “partial outage” for 1 week at this point (and for any customers with the new editor, the status is effectively “full outage”).

The silence from Atlassian on the related JAC tickets (and here in this discussion) is deafening.

In our opinion, if no imminent fix is forthcoming, any Confluence Cloud instances that have already been upgraded to the new editor (including blog posts…which is most Cloud instances) should be immediately rolled back.

Have you raised a report on the Developer Support portal? https://ecosystem.atlassian.net/servicedesk/customer/portal/14

No I haven’t, I assumed the existing CONFCLOUD tickets were sufficient and didn’t want to create duplicates.

If you think it would help raise the awareness of the problem, I can certainly create a Dev Support portal ticket.

EDIT: Dev Support ticket now logged (https://ecosystem.atlassian.net/servicedesk/customer/portal/14/DEVHELP-2313)

I only suggested it because it seems like the right avenue for the help you’re seeking. You’re a developer and you need support. :slight_smile:

1 Like

Atlassian has provided the following comment on CONFCLOUD-64923:

(emphasis mine)

There are couple of issues that we are aware of relating to dynamic content macros and the new editor. We have been working on resolving them but it’s taking a longer time than we expected. We are treating these issues as blockers to further editor rollout and are targeting to fix them in the upcoming weeks

This would seem to imply that:

  • every blog post (for all Confluence Cloud instances), and
  • every page (for those canary instances that have already been upgraded to the new editor)

…impacted by the new editor bugs will potentially remain broken for weeks.

To me, this is unacceptable.

Is it reasonable for customers to experience a multi-week outage to our apps, while Atlassian works through teething issues with their new editor?

I believe that not only should these issues be “blockers to further editor rollout”, but that Atlassian should be actively rolling back all instances to the old editor until these issues are resolved.

1 Like

I’m not stating an opinion one way or another, but I would guess that if they haven’t rolled it back yet, they made a one-way conversion with no ability to roll back. They haven’t rolled back because they can’t.

Just a guess, really.

Weeks indeed seems way to long to wait for a fix since the platform has broken your feature. Generally, the platform should be committed to its vendors and their uptime.

1 Like

I’ve checked this issue and linked it to https://jira.atlassian.com/browse/CONFCLOUD-64923. Updates and communications will be consolidated in the public-facing issue CONFCLOUD-64923 in order to have one issue to track.