by Carlos Vasquez
One of the powerful new features introduced with Confluence 6.0, collaborative editing, allows multiple users to edit a document together in real-time. Under the hood, the Synchrony service keeps tabs on all the moving parts and performs the necessary behind-the-scenes magic to make this feature a breeze to use.
A client had recently attempted to enable collaborative editing only to find that on doing so, attempting to edit a page would hang indefinitely with a loading indicator and dimmed elements. Disabling it became the only solution if any work was going to get done so they turned to Isos for help.
First Signs of Trouble
Now, while Atlassian recommends running Synchrony on the same server with Confluence, this particular deployment was using a separate Synchrony cluster created from the AWS quick start template they provide (currently not a recommended production-ready solution). The cluster sat behind the same AWS load balancer that Confluence did, being SSL terminated at the same domain. But despite being configured as specified in the documentation (https://confluence.atlassian.com/doc/set-up-a-synchrony-cluster-for-confluence-data-center-958779073.html), particularly synchrony.service.url using an http scheme and /synchrony/v1 path, collaborative editing was simply not working.
Something is Very Wrong
Every nook and cranny of the configuration was checked, and yet, infuriatingly, there were no indicators of any status issues (https://confluence.atlassian.com/confkb/how-to-check-the-status-of-synchrony-for-confluence-data-center-953651062.html). When enabled, the health check passed. The Synchrony plugin status check passed. Even the websockets check passed. Worse, when attempting to edit a page, although hung, the Synchrony application logs simply showed 200 OK messages for every single request!
It was a complete head scratcher as hours went by searching the documentation, community pages and submitted bugs. It was really starting to look like the client was to forever keep the feature off as all hope was lost...
...or was it?
A Glimmer of Light
Opening the browser's developer console to inspect the network traffic for any clues at first showed nothing out of the ordinary. Everything was a 200 OK. Then suddently, one of dozens of heartbeats appeared in red, blocked due to a Cross Origin violation for using http instead of https. And the light bulb went off.
Revisiting documentation, it firmly pressed that Synchrony could not accept https traffic (https://confluence.atlassian.com/doc/possible-confluence-and-synchrony-configurations-958779064.html) and that it needed to be terminated at the load balancer, which it was. But given that, what about the service URL scheme? Did it really need to be http?
One additional indirect hint (https://confluence.atlassian.com/confkb/unable-to-edit-any-pages-in-confluence-6-x-due-to-collaborative-editing-867362716.html?_ga=2.73319635.1908663735.1549904237-1813561819.1548883944) for setups where Confluence and Synchrony run on the same server mentioned that the access URL in the search bar and the Server Base URL in Confluence's configuration page had to match. These were https.
That provided enough motivation to give it a shot. What else was there to lose? Confluence and then Synchrony were shut down and the synchrony.service.url scheme was updated from http to https. Back up with collaborative editing turned on, all health checks passed without a hitch. Fingers crossed, a page flipped to edit mode without a stutter. Testing with others, collaborative editing was finally working! The client was ecstatic.
In the end, who would have thought one tiny letter could make such a huge difference.