Ressource non mise en base via hydra

[maudetes]

Cette ressource distante n'est pas mise en db par hydra, même lorsqu'elle est rajouté aux exceptions. Reproduit en local.

Une piste d'explication du problème pourrait venir du content-type: En effet, le header Content-Type retourne application/octet-stream sur la ressource (hébergée sur minio). Pour deviner si un fichier est tabulaire on appelle la fonction : https://github.com/datagouv/hydra/blob/41981706bf75529158efa354c0c55d8ff0e1827f/udata_hydra/analysis/resource.py#L61 Or, application-octet-stream retourne True que dans le cas d'un csv.gz, ce qui n'est pas notre cas. Devrait-on considérer un application-octet-stream comme un csv éventuel ou doit-on faire en sorte que le fichier original ait un meilleur Content-Type? Qu'en est-il des autres fichiers csv sur minio? L'analyse du mime-type par la suite devrait-elle override is_tabular si on a détecté text/csv?

Autre piste : la tâche d'analyse est trop longue et le worker se fait kill ?

[Pierlou]

It seems that client.fput_object() sets the content-type to application/octet-stream by default. Good news is that the function has the option to customize the content_type, and it's already set up in the code, we're just not using it enough 🙃 I'll try something to make it happen, it should fix everything downstream

Update : avec cette PR on récupère le mime type s'il n'est pas spécifié, et maintenant les headers des fichiers des éléctions donnent : {'Server': 'nginx', 'Date': 'Fri, 21 Jun 2024 12:19:39 GMT', 'Content-Type': 'text/plain', ... 🎉

Update 2 : end-to-end successfully tested locally!

[Pierlou]

Apparemment tu as laissé l'id de la ressource dans la liste des exceptions, elle est explorable 🥳