|
II. O quase-acidente
Bastidor real: precisávamos mudar o horário de edições que já estavam agendadas no Beehiiv. Pela API, o caminho pra reagendar um post confirmado é deletar e recriar com a data nova. Parece operação burocrática, de rotina. Tem uma armadilha dentro.
Se a data de agendamento estiver no passado na hora do recreate, o Beehiiv dispara o envio imediato pra lista inteira. Sem confirmação, sem aviso, sem botão de arrependimento. A plataforma interpreta "agendado pra antes de agora" como "manda já".
A gente quase queimou uma edição fora de hora exatamente assim. Uma edição saindo no horário errado parece detalhe até você lembrar do que ela carrega: a promessa da página de cadastro, o ritual do leitor e, no nosso caso, conteúdo pensado pra data certa.
O pior dessa categoria de erro é que ele é silencioso até ser irreversível. Um typo no assunto você corrige na edição seguinte e pede desculpa. Um disparo pra lista inteira na hora errada já aconteceu: o email está nas caixas de entrada, e a única coisa que sobra pra gerenciar é a consequência.
Do susto saíram três regras internas, e elas valem pra qualquer fila agendada no Beehiiv.
Regra um: nunca recriar um post com horário no passado. A data nova entra validada antes de qualquer delete, e ela precisa estar no futuro com folga, sem exceção.
Regra dois: conferir o relógio do servidor, sempre. O fuso da plataforma e o seu relógio local podem discordar. O horário que importa é o que o servidor entende, e a diferença entre os dois é exatamente o tamanho da janela do acidente.
Regra três: mudança de horário acontece com a fila parada. Mexer em agendamento enquanto outra rotina mexe nos mesmos posts é receita de envio duplo. Pausa, muda, confere, religa. Trinta segundos de checagem custam menos que um pedido de desculpas pra lista inteira.
|