# mxout tick

Provoca o servidor a drenar a fila. É o que o cron chama.

mxout tick

{"ok":true,"ocupado":false,"tentados":2,"entregues":2,"falhos":0,"reagendados":0}

Sai 0 em sucesso e 1 se não conseguir falar com o servidor.

# Por que um subcomando, e não um processo que trabalha

O tick não abre o banco: ele faz uma chamada HTTP no loopback (POST /queue/tick) e o servidor é quem drena.

Isso não é preferência, é obrigação. O banco embarcado aceita um processo por vez — um segundo processo abrindo o mesmo arquivo esbarraria no lock do servidor. Então o cron toca a campainha; quem trabalha é quem já tem o banco aberto.

# Sem segredo no crontab

O subcomando lê MXOUT_AUTH_TOKEN do próprio ambiente do processo. Rodando via docker exec, o container já tem a variável, então a linha do cron não carrega credencial nenhuma:

* * * * * docker exec dev_mxout /mxout tick >/dev/null 2>&1

# Intervalo

Um minuto é o padrão razoável: no modo assíncrono a mensagem espera no máximo esse tempo. Num relay deliberadamente lento — envio serializado, atraso forçado — isso não destoa.

Se o intervalo incomodar para algum caso específico, o modo síncrono continua existindo: sem MXOUT_REDIS, a entrega acontece dentro da própria requisição.

# Ver também

• Fila — estados, backoff e retenção
• mxout check — diagnóstico de DNS