AkôFlow Server - Suporte a download dos arquivos das atividade

[ovvesley]

Atualmente, os arquivos de execução de atividades são salvos em um volume persistente externo ao AkôFlow Server. Para permitir que usuários façam o download desses arquivos diretamente via API, será implementado um fluxo baseado em agentes temporários que acessam o volume e transmitem os dados em tempo real para o cliente final.

⸻

🎯 Objetivo

1. Implementar um fluxo síncrono de download de arquivos, onde o AkôFlow Server:
2. Recebe a requisição de download (GET /download/{activity_id}/{filename})
3. Cria um pod temporário (agente) no cluster Kubernetes com o volume da atividade montado
4. Aguarda o agente estar disponível
5. Faz uma requisição HTTP para o agente, que lê o arquivo do volume e o entrega como stream
6. O AkôFlow Server transmite esse conteúdo diretamente para o cliente via io.Copy
7. Após o término do stream (download completo), o AkôFlow exclui o agente

⸻

🧱 Arquitetura

Cliente ⇄ AkôFlow Server ⇄ Agente ⇄ Volume

• O agente será um servidor HTTP simples em Go (ou equivalente), que terá o volume montado e exporá uma rota como:

GET /internal-download/{activity_id}/{filename}

• O AkôFlow Server atua como um proxy entre o cliente e o agente:
• Quando o cliente requisita um download, o AkôFlow orquestra o agente e inicia o stream assim que o agente responde.
• O stream deve ser síncrono e contínuo, sem buffer intermediário.

⸻

📌 Requisitos

• Criar um agente leve (container HTTP) que tenha o volume montado e sirva arquivos sob demanda
• O agente só deve responder enquanto estiver servindo o arquivo, sendo finalizado após o término do stream
• AkôFlow deve criar dinamicamente o pod do agente com base na activity_id
• AkôFlow deve aguardar o pod ficar pronto (Running + readiness check)
• Após stream concluído (com io.Copy), o agente deve ser removido automaticamente
• Lidar com falhas de rede, pod que não sobe, ou arquivo não encontrado
• Implementar a rota GET /download/{activity_id}/{filename} no AkôFlow Server

⸻

🔐 Considerações

1. O agente não deve estar exposto publicamente. A comunicação entre AkôFlow Server e agente deve ser interna (dentro do cluster).
2. O volume deve ser montado com acesso somente leitura.
3. Podem ser usados Jobs ou Pods com restartPolicy: Never, conforme a estratégia mais simples.
4. TTL automático pode ser considerado se for garantido que o Pod só morre após o fim do stream.

⸻

🧪 Testes esperados

✅ Arquivo grande deve ser baixado corretamente sem interrupção
✅ Download deve começar imediatamente (stream)
✅ Download incompleto se o cliente interromper
✅ Agente é destruído após término
✅ Resposta HTTP correta com cabeçalhos de download

⸻