A extração do conteúdo não consegue encontrar os arquivos locais:

maria-quiteria-worker-1  | [2021-10-04 04:19:58,879: INFO/MainProcess] Task web.datasets.tasks.content_from_file[5f297b9e-c1cb-4a53-874d-e8754532ad3b] received
maria-quiteria-worker-1  | [2021-10-04 04:19:58,891: INFO/ForkPoolWorker-5] Arquivo /code/data/tmp/maria-quiteria-local/files/citycouncilminute/2021/10/4/ata45.pdf não encontrado.

Ao executar os métodos de maneira separada é possível ver que os arquivos são criados. O problema é que eles estão em containers diferentes. Provavelmente o container que executa o crawler e salva o arquivo local não é o mesmo que processa as tasks de backup e extração de conteúdo. Uma solução para isso seria utilizar volumes.

Por conta do crawler do TCM-BA temos abordagens diferentes: para ele salvamos os arquivos localmente em tempo de execução (por conta de limitações do crawler) e para os demais baixamos o arquivo a partir de background tasks. Acho que podemos dar uma olhada no processo em geral para melhorar a parte local e de testes também.

cc @cuducos

Eu acho que o problema não é só esse dos volumes. Adicionei no worker o volume .:/code, assim ele acessa o mesmo /code/data/tmp do volume do Scrapy. Mas acho que o problema está na lógica do cliente S3. Só acho código que baixa o arquivo no clienet S3, mas em ambiente de esenvolvimento usamos o fake que é um Mock().

Com isso nunca chegamos a fazer o download do arquivo usando o campo File.url — isso só ocorre no clienet S3 de verdade até onde eu consegui entender…

Faz sentido ou estou deixando passar alguma coisa?

Hum… olhando melhor o código, na verdade o refactor precisa ser maior, pois o content_from_file e o File dependem de coisas do S3 (ao menos na semântica): coisas como download_file, s3_url e s3_file_path não fazem sentido para armazenamento local. Em outras palavras, tanto modelo, quanto tarefas, quanto serviços estão acoplados ao S3.

Minha sugestão aqui seria um refactor mais drástico: criar uma API interna para modelos, tarefas e serviços que não acople a dependência nem do S3, nem de um armazenamento externo, isso — talvez o Django Storages ajude aqui.

O que acham?

Em alguns testes que eu fiz, eu tive problemas na hora de baixar e salvar arquivos muito grandes (2GB aprox). Pelo que entendi/percebi, é porque antes de salvarmos em um arquivo, todo o conteúdo fica em memória e no momento de salvar gera um problema.

Concordo com você @cuducos que essas funções/métodos não são responsabilidades do S3 e estou dando uma olhada como podemos melhorar essa parte. Outra coisa que tbm estou dando uma olhada é que nós baixamos o arquivo, enviamos para o S3, depois nós baixamos o arquivo do S3 para processar no Tika. Estou tentando dar uma refatorada nessa parte de arquivos.

Fiz um gist para validar algumas ideias (link aqui) antes de fazer algo no código. Estou com as mudanças até bem adiantadas, tive um problema pra pegar a chave do S3 mas ja deu bom tbm.

@cuducos @anapaulagomes cês acham válido a gente marcar uma chamada pra conversarmos sobre esses pontos?

Ontem troquei uma ideia com o @cuducos pra explicar melhor o porquê está assim. Vou tentar colocar aqui mas acho que vale a pena a gente trocar uma ideia (entro de férias logo mais então só semana q vem :) mas fiquem a vontade).

Em alguns testes que eu fiz, eu tive problemas na hora de baixar e salvar arquivos muito grandes (2GB aprox).

O tamanho é até configurável no Scrapy mas é um problema mesmo. Alguns arquivos vem dos sites muito grande (especialmente aqueles .rar com decorações de natal haha é sério)

Outra coisa que tbm estou dando uma olhada é que nós baixamos o arquivo, enviamos para o S3, depois nós baixamos o arquivo do S3 para processar no Tika. Estou tentando dar uma refatorada nessa parte de arquivos.

Espera pra conversar com a gente ou com o Cuducos antes de ir a fundo na implementação essa semana pq provavelmente essa estratégia vai mudar. Era dessa forma porque usávamos o Heroku, então não podíamos contar com os arquivos salvos em disco (como o Scrapy salvava antes, através de pipelines). Então começamos a usar background tasks pra poder gerenciar melhor essa limitação.

Atualmente temos um outro problema: o crawler do TCM-BA precisa salvar o arquivo em tempo de execução porque não temos acesso a uma URL única pra cada um. Uma alternativa seria: passar a salvar todos os arquivos localmente para fazer o backup, extrair o conteúdo e então apagar. Vamos precisar discutir com o @gomex essa parte porque tem toda a arquitetura envolvida pra isso acontecer.

Abri um PR para resolver o problema a nível local (#412). Vamo pensar como resolver isso de maneira mais otimizada em termos de custo e melhor para manter no futuro.