O horário era 9h44 e foi feito 14 horas antes. A próxima tentativa seria 10 horas depois, significando algo como 19h44. Eu esperava que fosse logo após a meia-noite e uma vez por ano, como o cron funcionaria.
O job está agendado para rodar uma vez a cada 24 horas durante o mês de janeiro: discourse-yearly-review/app/jobs/yearly_review.rb at main · discourse/discourse-yearly-review · GitHub. Se um tópico for encontrado no site com um título que corresponda ao título do tópico de revisão, o job não será executado novamente. Isso significa que apenas 1 tópico de revisão será gerado, a menos que você edite o título do tópico de revisão após sua criação.
Isso é 31 vezes até que um tópico adequado seja encontrado, algum tipo de proteção? Ou temos uma barreira linguística aqui? As chances são altas para isso também
Mas… eu ainda não entendo os timestamps. Às 9h44 do dia 1º de janeiro, o sidekiq diz que YearlyReview foi acionado 14 horas antes, em 31 de dezembro.
Novamente — isso não é um problema de forma alguma. Estou apenas tentando entender, porque tenho muito tempo livre.
Meus usuários ficariam bastante ansiosos se tivessem que esperar mais 10 horas para obter essas preciosas estatísticas, embora. Bem, eu sei como acionar o sidekick, então problema resolvido
Sim, ele está lá para evitar que o trabalho seja executado acidentalmente fora do primeiro mês do ano. Observe que, se você acionar o trabalho do console com o argumento force: true, os tópicos de revisão poderão ser criados fora do primeiro mês.
É realmente necessário? Tive que ir excluir tópicos duplicados e desativar o plugin em algumas das minhas instâncias. Isso não é um grande problema, mas parece desnecessário.
Durante o Ano Novo, os administradores costumam ficar longe de suas instâncias por vários dias - se não direcionaram o plugin para uma categoria privada agradável e restrita, o que não é ideal.