I noticed the jbrowse.org/code/jb2/main was displaying a broken page and this was likely due to cloudfront aggressive caching
Random note 1: the fact we see broken content could be a hint that doing "aws sync --delete"(specifically the delete) is dangerous as it deletes some backing files that would otherwise get served by the cache...you can imagine if someone is running a particular "version" of jbrowse.org/code/jb2/main (whatever was there when they visited) then deleting the backing files while it is running could cause them to get missing files all of a sudden. that's a tricky weird thing and just leads to the conclusion that you can never delete....or at least delay delete but that seems hard without meticulous tracking. but not doing delete keeps a lot of old files around...
I noticed the jbrowse.org/code/jb2/main was displaying a broken page and this was likely due to cloudfront aggressive caching
Random note 1: the fact we see broken content could be a hint that doing "aws sync --delete"(specifically the delete) is dangerous as it deletes some backing files that would otherwise get served by the cache...you can imagine if someone is running a particular "version" of jbrowse.org/code/jb2/main (whatever was there when they visited) then deleting the backing files while it is running could cause them to get missing files all of a sudden. that's a tricky weird thing and just leads to the conclusion that you can never delete....or at least delay delete but that seems hard without meticulous tracking. but not doing delete keeps a lot of old files around...
Random note 2: I was curious if we were breaking the bank per-se with doing many create invalidations, e.g. if it was per file in the directory, that would be expensive, but i think with the wild card paths, it is just 1 cost and not multiplied by every file in the directory https://aws.amazon.com/developer/application-security-performance/articles/cost-optimization/