We have discovered a regression in Firefly release-2019.3.1. This release contains part of a major re-engineering of the handling of complex table data types (tables with columns that are not simple scalars or strings). This work will not be complete until the next major release, a few months' time; meanwhile, it has been noticed belatedly that, although all other existing Firefly applications are working, the partially completed change has broken the handling of the complex data type used to send LSST detection footprints to the display client.

We need to deploy release-2019.3.1 as part of the LSST Portal application, because it contains the code to adapt to the recent change in LSST's TAP service's asynchronous query authorization, but we do not want to break things for users of the footprint visualizations.

We are evaluating how to proceed. One option is to keep using release-2019.2-based code on lsst-demo for general visualization use, while deploying 2019.3 for the Portal. This would require keeping the lsst-demo "override" in place for another few months.

Another might be to cherry-pick the TAP authorization logic change back to 2019.2, but that may be a fairly major effort.