> 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/construir/testar-depurar-e-observar/como-depurar-com-time-travel-debug.md).

# Como depurar com Time Travel Debug

Como reproduzir na sua IDE uma execução que aconteceu em produção, com os argumentos e os resultados de command originais, e depurar passo a passo o que a function fez.

## O que é

O Time Travel Debug reexecuta uma function localmente a partir do histórico de uma execução real. O runtime, em modo de depuração, lê uma captura dos passos gravados e faz o replay: a function roda desde o início na sua máquina, e a cada `await` de command o runtime devolve o resultado que foi gravado em produção, sem chamar o gateway, o banco ou a API de verdade. Você coloca breakpoints na function, inspeciona variáveis e vê exatamente o caminho que ela tomou, com os dados de lá.

Ele reproduz o que aconteceu; não é um teste de integração e não substitui um.

## Pré-requisitos

O mesmo código (mesma versão) que estava publicado quando a execução rodou. Se o fluxo da function mudou desde então, o replay diverge, como divergiria em produção.

## Passo a passo

1. No Monitor, abra a execução que quer depurar e exporte a captura da execução. Salve o arquivo localmente (ou copie a URL).
2. Configure o runtime local em modo de depuração, apontando para a captura (o arquivo salvo ou a URL). Nesse modo o runtime lê a captura em vez de buscar trabalho no skail, processa essa única execução e não grava nem confirma nada. Nada sai para o skail nem para os seus sistemas.
3. Coloque breakpoints na function e inicie com o depurador da IDE (F5 no Visual Studio, Debug no Rider ou VS Code), com o modo de depuração configurado no perfil de execução.
4. O runtime entrega a execução da captura uma vez. A function roda desde o início; em cada command, o depurador para no seu breakpoint e, ao continuar, o runtime devolve o resultado gravado. Você vê os argumentos, o retorno e as decisões que a function tomou com eles. Ao final, o runtime encerra, porque não há mais nada a executar.

O que você deve ver: a function percorrendo o mesmo caminho da execução de produção, com os mesmos valores, e o processo terminando sozinho no fim.

## Para que serve na prática

Entender por que uma execução falhou: você para no `await` que lançou e vê o argumento que causou a falha. Entender uma decisão inesperada: a function tomou o `else`, e você vê o resultado do command que a levou lá. Reproduzir um bug reportado pelo cliente sem tocar em produção e sem montar dados de teste.

## Limites

Os commands não executam: você vê o que eles devolveram, não pode reexecutá-los com dados novos. Uma execução que hibernou (delay, evento) é reproduzida até o ponto de hibernação e a partir dele, conforme os passos da captura. Se o código mudou de forma incompatível, o replay diverge e lança `SkailNonDeterministicException`, o que por si só já é diagnóstico. Não use a URL assinada de uma captura em documentação ou repositório; ela dá acesso aos dados da execução.

## Próximos passos

[Monitor](/construir/portal/monitor.md) para encontrar a execução. [Time Travel Debug](/construir/portal/time-travel-debug.md) é a referência curta. [Determinismo e replay](/aprender/fundamentos/determinismo-e-replay.md) explica o mecanismo que torna isso possível.