Concentrateur IRVE dynamique national #3839

thbar · 2024-03-25T15:48:27Z

Cette PR implémente un concentrateur IRVE dynamique national dans le proxy du PAN.

L'idée est d'être en mesure de fournir, pour les réutilisateurs, une url unique nationale pour disposer des informations de disponibilité des points de charge (en état / hors-service, utilisé ou pas etc) conformément au schéma IRVE dynamique (https://schema.data.gouv.fr/etalab/schema-irve-dynamique/).

L'url sera référencée comme une ressource du PAN.

Cela complète la consolidation IRVE statique déjà en place (https://transport.data.gouv.fr/datasets/fichier-consolide-des-bornes-de-recharge-pour-vehicules-electriques), et permettra de donner aux réutilisateurs une vision complète (emplacements, caractéristiques, et disponibilité des points de charge).

Voir:

Sélection des jeux IRVE dynamiques pour le concentrateur #3818
https://github.com/etalab/transport-proxy-config/pull/95 pour la configuration qui ira en prod (sachant que le jeu Eco-Movement n'est pas valide et sera corrigé par le producteur, ce qui fait ne fait un bon test d'erreur en réel Jeu IRVE dynamique "valide mais pas valide" & notre usage de la spéc FrictionLess vs Validata #3895)

Principe général:

un nouveau type d' "item" du proxy est introduit dans la configuration, appelé "aggregate".
cet "aggregate" dispose de sous-flux, identifiés par une chaîne de caractère, avec leur propre TTL et url cible.
le traitement de cet item "aggregate" donne lieu à N sous-requêtes concurrentes, qui sont consolidées dans l'ordre de la configuration de façon déterministe.
les champs doivent être (comme le dit la spécification Frictionless) exactement présents et exactement dans l'ordre (je m'appuie dessus pour simplifier le code et le rendre plus efficient, sachant que cette implémentation se traduira par des requêtes potentiellement nombreuses à terme)
le schéma suivi est https://schema.data.gouv.fr/etalab/schema-irve-dynamique/ ; une validation temps réel et reformattage à la volée sera possible vu l'architecture mise en place, toutefois on va d'abord aller recruter des flux pour avoir suffisamment de cas d'usages
chaque "sous flux" est mis en cache (si on a un retour HTTP formé correctement) dans Cachex
le flux global n'est lui pas mis en cache actuellement volontairement, pour le moment en tout cas

Améliorations à prévoir pour le futur

Le code lié à la gestion de Cachex était déjà un peu compliqué, et son usage augmente avec cette PR. Le fait qu'on n'utilise pas une "behaviour" et un isolement fait qu'on utilise de fait réellement Cachex dans chaque test, ce qui introduit des complexités (état partagé).

Ce point sera retravaillé dans une prochaine passe.

On voit également des aspects "GBFS" dans le code du proxy, qu'il faudra déplacer probablement dans shared.

Certains éléments gagneraient à être renommés, mais cela aurait rendu la PR trop complexe, j'ai préféré repousser à plus tard.

Le logging (Logger.info d'ailleurs souvent comme relevé par @ptitfred) pourra être amélioré, et avec lui peut-être un traçage des codes HTTP avec des time-series à un moment.

Comment tester sur `prochainement`

# flux complet
curl https://proxy.prochainement.transport.data.gouv.fr/resource/consolidation-nationale-irve-dynamique

# avec limite par source pour y voir plus clair
curl "https://proxy.prochainement.transport.data.gouv.fr/resource/consolidation-nationale-irve-dynamique?limit_per_source=1"

# avec l'identifiant de chaque source (origine)
curl "https://proxy.prochainement.transport.data.gouv.fr/resource/consolidation-nationale-irve-dynamique?include_origin=1&limit_per_source=1"

Test en local

Prendre la configuration sur:

https://github.com/etalab/transport-proxy-config/pull/95/files

Puis:

curl "http://proxy.localhost:5000/resource/consolidation-nationale-irve-dynamique?limit_per_source=1"

See frictionlessdata/frictionless-py#1646

Also link to #3975 which can lead the maintainer to a problematic database situation.

After verification, `@proxy_requests` is only referenced inside the same file, and only for unsorted guard checks.

The same character is used, but 97800f3 incorrectly conflates telemetry events (metrics) with cache keys.

thbar

Déjà re question de Frédéric sur le script scripts/irve/dynamic-irve.exs:

Je ne suis pas sûr de comprendre l'objet des changements dans le script

Je cherchais à voir la validité des données "remote” sur les fichiers utilisés pour IRVE dynamique (dont j’avais besoin), à débugger pour chercher à comprendre pourquoi data.gouv ne rapportait pas le fichier comme ayant subi la validation, et afficher des stats. Plutôt du script de mise au point de la config utilisée ici, donc.

Par ailleurs - merci pour les nombreux retours à tous les deux, j’ai pu réaliser les améliorations et corrections suivantes (voir diff spécifique c’est plus simple à suivre):

ajout de typage sur les paramètres pour que la lecture soit plus aisée
ajout de tests sur le parsing de la configuration YAML dans le cas aggregate
refactoring pour éviter le passage de fonction get_function en paramètre (trop compliqué et pas clair en maintenance / lecture), au profit d’options du style max_redirects: 2 plus claires
ce qui a impliqué le déplacement de la gestion des redirects (nouvellement nécessaire pour le support des urls stables de data gouv, dont on se sert pour les IRVE) d’une couche haute du code vers le wrapper Finch (refactoring)
ajout de tests pour le wrapper Finch, qui devenaient nécessaires (les chemins de code 302 réimplémentés dans le wrapper étaient non testés en particulier, et error-prone avec de la récursivité)
ajout de Bypass (mini-serveur web de test) pour tester correctement le wrapper Finch
correctif d’un bug qui aurait mal compté les requêtes “internal” sur les sources agrégées, avec une solidification des tests associés (🙏 @AntoineAugusti pour la question portant sur le test, qui m'a mis sur la voie)
DRY des déclarations de séparateurs de clés : pour le cache
clarification du désenregistrement des handlers de télémétrie en début de tests, que je ne comprenais pas (passage de Enum.at(1) à Enum.uniq, qui fait la même chose mais qui fait qu’on ne se pose plus la question en lecture de code).
une fois que c’était fait, j’ai pu DRYer @proxy_requestsqui était en double (quoiqu’à l’envers) d’un autre attribut suite à refactoring, sans risque à présent.

Voilà je vais déployer tout ça sur prochainement pour vérifier que rien n'a cassé.

thbar · 2024-05-20T18:26:34Z