Invalid requests for the `reportSingleTable` partial
What's the issue?
reportSingleTable partial, a file removed awhile ago, is still being requested by the client via this file's (now defunct) entry in the reports'
urls.py file. Django throws a 500:
Internal Server Error: /platform/reports/partials/reportTable/ TemplateDoesNotExist at /platform/reports/partials/reportTable/reports/partials/reportSingleTable.html
The only reason that Django is throwing a 500 at not being able to find a resource (instead of a 404) is because this removed file is still registered in the
partial_patterns = [ #... url(r'^reportTable/$', views.PartialGroupView.as_view( template_name='reports/partials/reportSingleTable.html', ), name='table', ), #... ]
If I had properly removed all references to this file (oops) this bad request would have returned a 404 and we wouldn't have been alerted.
How is this happening?
After looking into how this file is being requested, I'm guessing that this is an issue with client-side caching. Browsers cache HTML/JS often, assuming that once you visit a page that you are willing to sacrifice disk space to revisit the page faster. I believe that (some?) browsers are keeping old versions of the BEAT platform's client files in the cache. These old files have the old code in them, and request the old resources.
This almost always isn't a problem, since it's easy to compare file versions and invalidate the cache appropriately. However I've had this problem before when working locally & on staging. I figured it was just because of how quickly I switched through different versions of the BEAT platform, but I think it's happening on prod to normal users too.
Why would this be an issue for us and not for 99% of other websites? Honestly I don't understand enough right now to answer that. I do know, however, that servers can influence the caching of browsers...we might not be handling things properly.
What do we do?
There's still a small chance that this issue isn't caching, which would be much easier to solve. We should look into the issue a bit more. If it really is a caching issue, we'll have to do a few things:
- We may have to ask users to manually clear their cache for the BEAT platform. As Andre suggested, we can add this to the FAQ.
- There's probably other resources being requested by old caches that aren't throwing 500s but 404s instead. We might want to monitor 404s for now as well as 500s.
- There might be a fix on the Django side to automatically/manually invalidate existing caches. Maybe we aren't doing something properly when serving the client files?
- Client-side, we should check to see if bad requests are handled properly so the user is aware of the issue and of potential fixes (such as looking at the FAQ, clearing the cache, filing a bug report, etc.).
- We'll want to try to reproduce the cache issues (maybe even add a test for it?). The complexity of the problem is greater than our testing infrastructure, so this would take awhile.