Si tratta di WP self-hosted su nginx+php-fpm 8.3 con caching fast-cgi di nginx per contenuti dinamici e caching di oggetti Redis (con il drop-in object cache attivo). Non ci sono altri livelli (nessuna CDN, nessun CF, nessun Varnish on-box o altra cache locale oltre alla cache fast-cgi di nginx). Scaricare la cache fast cgi di nginx (aggressivamente, andando su rm -rf /etc/nginx/cache/*) non ha alcun effetto sul comportamento problematico: vengono serviti risultati obsoleti anche dopo aver svuotato la directory della cache e riavviato sia nginx che php-fpm.
Ho effettivamente abilitato il caricamento dei commenti Ajax in questo momento, sì, ma di nuovo, disattivarlo (e scaricare la cache di nginx più riavviare nginx e php-fpm per sicurezza) non ha avuto alcun effetto sul comportamento problematico. I browser continuavano a ricevere commenti obsoleti.
Opzione disattivata, transient-killer rimosso. Nessun cambiamento nel comportamento problematico.
L’effetto che applica sembra essere la fornitura di un header cache-control no-cache invece di uno con un tempo di cache specificato. Senza di esso, il mio browser sembra voler molto servire una versione memorizzata nella cache obsoleta dell’endpoint wp-json/wp-discourse/v1/discourse-comments dalla sua cache del disco; come notato, devo premere shift-ctrl-f5 (o l’equivalente) per forzare un aggiornamento no-cache.
Il comportamento problematico sembra essere lato browser, piuttosto che in una cache persistente lato server. Sono solo tutti i browser su tutti i sistemi operativi a cui ho accesso che lo stanno facendo.