Front-end should poll app to see if update available

[exalate-issue-sync[bot]]

Set up the front end to poll fecfile-web-app and refresh itself when detecting a new deploy.

When we deploy new builds of the app, the file bundle that the user’s browser downloads has a unique filename. If the user has the app open, and a new deploy occurs to cloud.gov, the open app will not have urls to the new bundle files. This can cause app failures as the front-end may be out of date and try to lazy load files that no longer exist.

See here for techinical details on how to do this: https://www.syncfusion.com/blogs/post/propagate-front-end-updates

Verify polling will not cause undesired performance implications

Preferably we don’t download the whole app when checking the “hash”

QA Notes

Devs will add screenshots for QA verification

DEV Notes

When looking at the homepage, the build hash is available in the HTML

!image-20240904-150434.png|width=1359,height=287,alt="image-20240904-150434.png"!

Design

null

See full ticket and images here: FECFILE-1564

[exalate-issue-sync[bot]]

akhorsand commented: [~accountid:712020:2a1493e5-adee-45bd-b27e-868a5c8d3f62] this ticket has points. Is there a follow-up needed before moving it to ASA? Also, what is the definition of done for the ticket (for example, do we have a metric for undesired performance implications? How do we follow-up if that’s the case?)

[exalate-issue-sync[bot]]

Todd Lees commented: The follow up was to add the last two sentences:

{quote}Verify polling will not cause undesired performance implications

Preferably we don’t download the whole app when checking the “hash”{quote}

done is the first sentence:

{quote}Set up the front end to poll fecfile-web-app and refresh itself when detecting a new deploy.{quote}

To test it we will have to have someone with a tab open, then deploy to the web app. It’s a success when it polls the web app server and notices that it’s out of date and refreshes.

Undesired performance implications would take the form of spikes on our application instance on cloud.gov

[exalate-issue-sync[bot]]

Todd Lees commented: sending back to in progress to either remove out-of-ticket features or to get design to add them in to the ticket

[~accountid:61b0b42cc510bc006b5c03ed] [~accountid:627ebeb2236090006f61d37d] could you sync next monday to determine if the confirmation dialog should be added to this ticket?

[exalate-issue-sync[bot]]

Sasha Dresden commented: After discussion a second ticket: [https://fecgov.atlassian.net/browse/FECFILE-1653|https://fecgov.atlassian.net/browse/FECFILE-1653|smart-link] was created to handle deploying previous build to those still using the old build.

[exalate-issue-sync[bot]]

Laura Beaufort commented: [~accountid:627ebeb2236090006f61d37d] I wanted to flag this aggressive caching behavior: [https://fecgov.atlassian.net/browse/FECFILE-1682|https://fecgov.atlassian.net/browse/FECFILE-1682|smart-link] , which might prevent any attempt to refresh the assets.

[exalate-issue-sync[bot]]

David Heitzer commented: Discussed the Cloudfront caching behavior this morning with [~accountid:5b92c509d0b4022bdc51bdf4] and [~accountid:627ebeb2236090006f61d37d]. Because Cloudfrount is caching for 24h, the polling will be delayed finding new updates for 24h in our environments (even though it might immediately find them locally).

[exalate-issue-sync[bot]]

Todd Lees commented: This ticket looks good. Moving to in progress to wait for FECFILE-1682