Saving updates to a survey XLSForm does not refresh Survey123 Connect Form Preview

[BrandonArmstrong]

When deploying a solution using the test deployment app (https://solutionstest.geocloud.com/online-test) the Form Preview of Survey123 Connect does not refresh after editing and saving an XLSForm.

When this workflow is attempted on a survey/XLSX file that was deployed with a solution from the production app, when an update is made in the Excel file and the ‘save’ button is selected in the Excel file, the Form Preview in Survey123 is automatically refreshed to reflect the update.

Note: In the scenario where the survey and Excel file is coming from the solutions test app, when the 'save' button is selected and the Form Preview does not refresh, the issue is resolved once the Update action is selected from Survey123 Connect

Expected behavior:

https://github.com/Esri/solution.js/assets/6314443/f6cb2ed3-dfe2-44f2-9ec1-0b4e056963de

Can reproduce using Dam Safety and Readiness Management (and any solution containing a survey)

[MikeTschudi]

This error occurs because we replace the contents of the text files in the survey configuration zip file. While this is implemented in order to swizzle the contents, no modification of the contents is needed to replicate this bug: we simply read and replace text files. While the XLSX file is also read, it is not replaced back into the zip--it is left alone.

[chris-fox]

This is occurring because the date timestamps for the files are showing in the future for some files. See the screenshot below, I just took this picture and the timestamps for the Sign Request.xml file is showing as tomorrow. Survey123 Connect compares the timestamp of the xlsx file with this .xml file. If the xlsx file has a modification date newer than the xml file then it refreshes the xml file from the xlsx definition. Because the timestamp of the xml appears newer than the xlsx even after I save it doesn't refresh.

The update forces the xml to update and its timestamp is updated to now as a result. Is there anything we can do to control the timestamp of these files when we replace these files in the zip? Not sure if this is some UTC offset going on here.

[MikeTschudi]

Thank you, @chris-fox, for discovering this.

I'm marking every file with the same time.

• xlsx earlier than xml causes this issue as you discovered
• xlsx later than xml causes infinite loop asking if we want to update the survey
• xlsx with same date as xml works

S123 does something strange while unzipping, however: it adds the UTC offset to all files except the PNG and .itemInfo files. This puts the XLSX file hours into the future west of the prime meridian, thus breaking the update.

Merely correcting for UTC offset for all files leads to S123 to unzip all files to be approximately the same time, but all files except the PNG and .itemInfo files are one day in the future.

Merely subtracting one day for all files has the same effect as setting all files to deployment time.

Correcting for UTC offset and subtracting one day seems to be the solution.