Erreur intermittente sur les tests UrlExtractor Opendatasoft

[thbar]

Un nouvel exemple de cas pour #1706, que je vois arriver souvent, donc je vais le traquer séparément:

1) doctest Opendatasoft.UrlExtractor.get_resources_with_url_from_csv/1 (6) (Transport.UrlExtractorDocTest)
     apps/transport/test/transport/url_extractor_doc_test.exs:4
     ** (EXIT from #PID<0.6152.0>) killed

J'ai vérifié dans un premier temps qu'aucune requête externe n'était émise, et en fait si aucun serveur n'est contacté, on fait quand même un HTTPoison.head sur une fausse URL. Je me demande s'il n'y a pas un souci de sync/async par rapport au fait que HTTPoison est modifié via with_mock.

On gagnera à utiliser le "shared impl" généralisé par @fchabouis dans #1745 sur cet extracteur.

Je crée le ticket pour qu'on revisite ça plus tard.

[thbar]

Je vois également dans les logs quelque chose qui touche à ça, qui ressemble à un vrai retour non stubbé (à vérifier, mais la date semble fraîche, sauf à ce qu'un stub modifie la date ce qui est également possible) d'un serveur OpenDataSoft:

11:24:37.984 [error] Exception %CaseClauseError{term: {:ok, %{body_byte_size: 144, hash: "be1bda66eeaaab1be5f304b109583f76436a22d0957779bcce5711edbf654a9f", headers: [{"server", "nginx"}, {"date", "Thu, 26 Aug 2021 11:24:37 GMT"}, {"content-type", "application/json"}, {"content-length", "144"}, {"connection", "keep-alive"}, {"content-language", "fr"}, {"content-security-policy", "upgrade-insecure-requests; frame-ancestors 'none'"}, {"access-control-max-age", "1000"}, {"expires", "Fri, 01 Jan 1990 00:00:00 GMT"}, {"vary", "Accept-Language, Cookie, Host"}, {"access-control-allow-headers", "Authorization, X-Requested-With, Origin, ODS-API-Analytics-App, ODS-API-Analytics-Embed-Type, ODS-API-Analytics-Embed-Referrer, ODS-Widgets-Version, Accept"}, {"pragma", "no-cache"}, {"cache-control", "no-cache, no-store, max-age=0, must-revalidate"}, {"x-frame-options", "DENY"}, {"access-control-allow-methods", "POST, GET, OPTIONS"}, {"access-control-allow-origin", "*"}, {"strict-transport-security", "max-age=15778800"}, {"x-xss-protection", "1; mode=block"}, {"x-content-type-options", "nosniff"}, {"referrer-policy", "strict-origin-when-cross-origin"}, {"x-ua-compatible", "IE=edge"}], status: 500}}} occurred during hash computation for url "https://ressources.data.sncf.com/api/v2/catalog/datasets/sncf-ter-gtfs/files/24e02fa969496e2caa5863a365c66ec2", returning empty hash

On a probablement un test "connecté" de plus, à remplacer.

[thbar]

L'erreur ci-dessus ressemble à ce qui est dans cette cassette à peu de choses près, peut-être qu'un call est bypassé.

Je vais voir si exvcr peut lever une erreur dans les cas où un appel extérieur est passé, si ce n'est pas déjà le cas.

[AntoineAugusti]

J'ai eu une erreur lié à ce test récemment. Ce n'était pas lié à une requête externe qui échouait, mais quand je référençais un asset (image dans mon cas) que je n'avais pas commit dans ma branche, et qui donc n'était pas trouvé à l'étape CI.

Fin mot de l'histoire ou rien à voir, à voir :)

[AntoineAugusti]

En lançant sans réseau

mix test apps/transport/test/transport/import_data_service_test.exs

je constate que les tests échouent. Les cassettes ne semblent donc pas utilisées ici. Je n'ai pas trouvé pourquoi, mais j'ai vérifié que TransportWeb.ExternalCase était bien chargé.

Un exemple d'erreur décrit dans #1757 (comment) sur CircleCI

[thbar]

Nouvelle occurrence https://app.circleci.com/pipelines/github/etalab/transport-site/2154/workflows/b65368d2-05e1-4b9b-ab7c-db9d8f9082f9/jobs/29098/parallel-runs/0/steps/0-102

[AntoineAugusti]

La PR #1863 semble résoudre le problème ! Je ferme, en espérant ne pas avoir à ouvrir à nouveau cette issue.