Dll Posted November 26 Posted November 26 Hi, we've just updated to the latest version and are having problems with updating the status of reports. It changes initially, but then reverts back to new report regardless of what's chosen. We've tried with all addons/themes disabled etc and have uploaded a fresh set of files, but still have the same issue, so it looks a lot like a bug.
Solution Dll Posted November 26 Author Solution Posted November 26 I think this is a caching issue our side, so please ignore. Marc and Daniel F 1 1
Fast Lane! Posted December 3 Posted December 3 I'm seeing the exact same thing. How did you fix it? I cleared caches but nothing is fixed.... reports say they are updated but when you refresh the screen they are not.
Fast Lane! Posted December 3 Posted December 3 (edited) It appears changing the status in an individual report "says" it's updated but then when you refresh the page it shows the old status: But when you update the status in the list view (below) it changes the status immediately and correctly (and when the page is refreshed the status stays). Thoughts/help/repro? @Daniel F @Marc seeing the same issue above. Just updated from .18 to .19. One area of the Mod CP works and another does not, when updating status. For debug steps, I use the default IPB skin (no changes) and I observe the same issue. I think this is a bug... Edited December 3 by Fast Lane!
Jim M Posted December 3 Posted December 3 Unfortunately, I am unable to reproduce this. Any status change whether on the report itself or on the list changes for me. Is this on a new report this is happening or an old report?
Fast Lane! Posted December 3 Posted December 3 On a report submitted before we updated. Let me check if new reports submitted after we updated work...
Jim M Posted December 3 Posted December 3 Old reports for me are already marked as Completed. Even if I change one to a separate status and reload the page, it is rendering the status I selected. I would suggest double checking your theme to ensure no templates are modified and checking your server for caching.
Fast Lane! Posted December 3 Posted December 3 (edited) New reports have the same issue. I can delete them on the ticket view (that works). 4 minutes ago, Jim M said: Old reports for me are already marked as Completed. Even if I change one to a separate status and reload the page, it is rendering the status I selected. I would suggest double checking your theme to ensure no templates are modified and checking your server for caching. I changed the theme to the default unmodified IPB theme. Can repro. Could this be a redis caching issue? Edited December 3 by Fast Lane!
Fast Lane! Posted December 3 Posted December 3 Update: I changed the caching method to filesystem and can repro. Changed back to redis and can still repro. @Jim M any other thoughts? Debug so far: 1) Set Theme for admin account to default (unmodified IPB) and can repro 2) Changed caching method to filesystem and can repro 3) Cleared cache on support page of ACP and can repro 4) Completed restart of apache/php and can repro 5) Completed full server reboot and can repro
Fast Lane! Posted December 3 Posted December 3 (edited) 6) I also purged my CDN end points to clear any items there that may have been cached. Issues still persists. 7) disabled 3rd party apps. Issues still persists. Edited December 3 by Fast Lane!
Fast Lane! Posted December 4 Posted December 4 (edited) So digging into browser debug data and server logs, I see that a 2 files (one css and on js) which are hosted on a subdomain and linked to a CDN.... are getting 504 gateway issues (time out / unreachable). Server logs show too many directs on those files. Did IPB change any redirect rule sets with this update that may have added an additional 'hop' which happened to put us over the limit? Not sure if this is the root cause at the moment. The files are: 97c0a48072ce601c9764cb6b00a6588a_page.css root_map.js Both are 504. Both are reachable via the folder but not the subdomain mapped to the CDN, as a 504 is generated when pulled from the subdomain. This started only after the .19 update. Given someone else saw this... perhaps there is an edge case bug here worth exploring? Edited December 4 by Fast Lane!
Fast Lane! Posted December 4 Posted December 4 (edited) Some preliminary testing shows if I bypass my CDN and route that traffic directly back to my server for those items this resolves. It doesn't explain why 2 of thousands of files at the CDN are 504'ing. This happened immediately when I upgraded to .19. No change to CDN or server config. Wondering what redirect rules or other items may have caused this with .19. I really don't prefer to not have my CDN sitting in front of my site (for obvious reasons).... Edited December 4 by Fast Lane!
Marc Posted December 4 Posted December 4 I cant see anything specific on a read through whats been changed, other than SEO redirects on post comments. But that would actually remove redirects, rather than add them. https://invisioncommunity.com/news/invision-community/invision-community-4-seo-prepare-for-v5-and-dormant-account-notifications-r1308/
Dll Posted December 4 Author Posted December 4 (edited) The reason we found for this was that we were using an 's3 compatible' storage bucket for the theme files, js etc (Cloudflare R2). We were 'mirroring' it from an S3 bucket for better compatibility (so we thought!) and it was fine up to the update but I assume something changed in the way storage buckets are handled during the update. The only way we found to fix was to switch back to (the recommended) actual Amazon S3 storage for them. Edited December 4 by Dll Marc 1
Fast Lane! Posted December 4 Posted December 4 (edited) 10 hours ago, Dll said: The reason we found for this was that we were using an 's3 compatible' storage bucket for the theme files, js etc (Cloudflare R2). We were 'mirroring' it from an S3 bucket for better compatibility (so we thought!) and it was fine up to the update but I assume something changed in the way storage buckets are handled during the update. The only way we found to fix was to switch back to (the recommended) actual Amazon S3 storage for them. This seems awfully similar (maybe the same) to what we experienced. Both of us had issues with an existing CDN with files breaking right after the .19 update. @Marc for thoughts if any. The root cause from what I can tell was with the 2 noted files having too many redirects and generating a 504 error. If it was a config issue I would have expected all files to break. Not just 2 very specific ones. Purging and refreshing those files didn’t fix it. Edited December 4 by Fast Lane!
Jim M Posted December 4 Posted December 4 7 minutes ago, Fast Lane! said: This seems awfully similar (maybe the same) to what we experienced. Both of us had issues with an existing CDN with files breaking right after the .19 update. @Marc for thoughts if any. The root cause from what I can tell was with the 2 noted files having too many redirects and generating a 504 error. If it was a config issue I would have expected all files to break. Not just 2 very specific ones. Purging and refreshing those files didn’t fix it. What CDN are you using? I am wondering if there is something specific there.
Recommended Posts