L’ora era le 9:44 e era stato fatto 14 ore prima. Il prossimo tentativo sarebbe stato tra 10 ore, quindi verso le 19:44. Mi aspettavo che succedesse poco dopo mezzanotte e una volta all’anno come funzionerebbe cron.
Il job è programmato per essere eseguito una volta ogni 24 ore per il mese di gennaio: discourse-yearly-review/app/jobs/yearly_review.rb at main · discourse/discourse-yearly-review · GitHub. Se sul sito viene trovato un argomento con un titolo che corrisponde al titolo dell’argomento di revisione, il job non verrà rieseguito. Ciò significa che verrà generato un solo argomento di revisione, a meno che non si modifichi il titolo dell’argomento di revisione dopo la sua creazione.
Quindi, 31 volte finché non viene trovato un argomento appropriato, è una sorta di misura di sicurezza? O c’è una barriera linguistica qui? Le probabilità sono alte anche per questo
Ma… ancora non capisco i timestamp. Alle 9:44 del 1° gennaio, sidekiq dice che YearlyReview è stato attivato 14 ore prima, il 31 dicembre.
Di nuovo, questo non è assolutamente un problema. Sto solo cercando di capire, perché ho troppo tempo libero.
I miei utenti sarebbero piuttosto ansiosi se dovessero aspettare altre 10 ore per ottenere quelle preziose statistiche, però. Beh, so come avviare sidekick, quindi problema risolto
Sì, è stato inserito per evitare che il processo venga eseguito accidentalmente al di fuori del primo mese dell’anno. Tieni presente che se attivi il processo dalla console con l’argomento force: true, gli argomenti di revisione possono essere creati anche al di fuori del primo mese.
È davvero necessario? Ho dovuto andare ed eliminare argomenti duplicati e disattivare il plugin su un paio delle mie istanze. Non è un grosso problema, ma sembra ingiustificato.
Durante il periodo di Capodanno, gli amministratori sono spesso lontani dalle loro istanze per diversi giorni, se non hanno indirizzato il plugin a una categoria privata piacevole e ristretta che non è l’ideale.