> For the complete documentation index, see [llms.txt](https://docs.skail.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skail.dev/construa/conceitos/hibernacao-e-retomada.md). # Hibernação e retomada Quando uma function chega em um ponto de espera, ela para de existir em memória e volta exatamente de onde parou quando a espera termina. Esta página explica a hibernação, a retomada e o que elas permitem.

Na primeira entrega, command 1 conclui e a execução hiberna no ponto de espera, sem thread, sem processo ativo e sem memória alocada para ela. Enquanto isso, a aplicação trata outras execuções, reinicia ou é atualizada. Na retomada, o replay traz command 1 e o ponto de espera do histórico, command 2 executa e a execução é concluída.

## Hibernar Hibernar é pausar a execução de uma function sem deixá-la rodando: sem thread, sem processo ativo, sem memória alocada para ela. Quando a function chega em um ponto de espera (uma espera por evento, um delay ou o `await` de uma function filha), o skail registra em que ponto a execução está e o que é necessário para continuar depois, e encerra a execução naquele momento. O processo da sua aplicação fica livre para tratar outras execuções, ou para ser reiniciado, atualizado e movido de servidor. Nada disso afeta a execução hibernada. ## Retomar Retomar é quando a execução hibernada volta a executar exatamente de onde parou, como se nunca tivesse parado. Quando o evento esperado acontece (um webhook, uma aprovação), o tempo do delay passa ou a function filha conclui, o skail entrega a execução de novo à sua aplicação. O runtime reexecuta a function a partir do histórico da execução: os passos já concluídos devolvem os resultados gravados sem rodar de novo, e o fluxo continua a partir do ponto de espera. Sem repetir o que já foi feito, sem recomeçar do zero e sem você controlar nada disso manualmente. O mecanismo por trás é o replay, explicado em [Determinismo e replay](/construa/conceitos/replay-e-determinismo.md). ## O que isso permite Fluxos que duram minutos, horas, dias ou meses sem manter nada rodando em segundo plano e sem perder o contexto da execução. Uma régua de cobrança de 30 dias, uma aprovação que leva uma semana, um processo que espera o retorno de um órgão público: cada um é uma function com um delay ou uma espera por evento, e o custo enquanto espera é zero. Isso se traduz em: * mais escala (um processo pequeno acompanha milhares de execuções em espera); * mais confiabilidade (uma queda no meio da espera não perde nada); * uso de recursos proporcional ao trabalho, não ao tempo de espera. ## O que muda para quem escreve código No código, nada muda: a espera é uma linha, o `await` de um delay de 30 dias. As consequências aparecem no restante do código: * o corpo da function será reexecutado na retomada, então ele precisa ser determinístico; * o código publicado no momento da retomada precisa ter a mesma sequência de `await`s, então mudanças exigem versionamento; * o estado que importa fica nos argumentos e nos resultados dos commands, não em campos da classe, que são descartados na hibernação. ## Próximos passos


Tempo e agendamento	Para como o delay funciona.	Tempo e agendamento
Eventos externos e correlação	Para a espera por evento.	Eventos externos e correlação
Versionamento de código com execuções em andamento	Para o que fazer antes de mudar uma function que tem execuções hibernadas.	Versões com execuções em andamento