When the Connect JS (ACJS) library passes values between an app and a product, they are sanitised before being posted between one window and another. This is done because some types can’t be cloned by the structured clone algorithm and would cause a runtime error. As a historic side effect of the implementation of the sanitisation function, null properties on objects - such as a JSON response from an API - are stripped from the object when being sanitised.
One of our product teams requested the ability to preserve null object properties in an API response. As this would be a breaking change to the ACJS API this ability was added via an opt-in property on the API method definition. The implementation missed the case where an API response is just plain null - which is what the AP.confluence.getContentProperty responds with in the case a content property does not exist.
The existing unit tests for the sanitisation function did not cover this case and the change caused a runtime error when trying to post the null response. The change was rolled back when we were alerted to the error. Tests have been added to cover this and other cases involving null values and properties.
For everyone’s information, it was me who raised the DEVHELP-5960 ticket in response to an incident where certain parts of our Confluence Apps stopped working suddenly and without warning, with no code changes having been made on our end.
The following method stopped functioning and started to throw the exception mentioned above:
com.atlassian.plugins.atlassian-connect-plugin:ap-core-v5.js?externals=_local-default_:54 Uncaught DOMException: Failed to execute 'postMessage' on 'Window': Symbol() could not be cloned.
We raised this through Atlassian at 13.00 on 31/Mar/21, however, we had reports of problems at least a day before this (probably due to gradual roll-out) and were investigating internally before raising with Atlassian.
I raised the ticket through the DEVHELP ‘report a critical bug’ mechanism, but am now aware that I should have used the ‘Critical Incident’ topic in the Dev Community, as this has some automation set up - so if anyone else has issues like this, the best way to raise them is through that topic rather than DEVHELP.
We were able to patch our Apps to use the AP.request() function instead, which unblocked our customers and the problem was resolved at source the next day, on 01/Apr/21, but a number of our customers were unable to use their products for 1-2 days due to the issue - far from ideal.
This change should not have been allowed to be released and I hope that in the future more thorough testing of any Public API’s will prevent this from happening again and from my discussions with the team, I am reassured that steps have been put in place to prevent this.