Validateur NeTEx : polling des résultats

[ptitfred]

Description

Cela permet de ne plus bloquer la queue de validation (que ce soit les ressources historisées ou on demand).

La première implémentation faisait le polling en Elixir, rendant un job bloquant le temps que la validation termine (ou timeout). Ceci créait de la congestion dans les queues de validation historisées ou on demand (surtout problématique pour l'historisé).

La nouvelle implémentation délégue le polling à 2 jobs

• 1 pour la validation historisée
• 1 pour la validation on demand

Checklist

• code non bloquant via des jobs
• adaptation de /backoffice/jobs pour afficher les jobs en attente
• tests unitaires
• tests manuels de OnDemand
• tests manuels de validation d'une ressource historisée
• tests manuels de validation concurrente de beaucoup de ressources historisées

Script de test manuel concurrent :

require Logger

Logger.info("Starting...")

import Ecto.Query

defmodule Script do
  # for each active dataset, grab all resources with a resource history.
  def query() do
    DB.Dataset.base_query()
    |> DB.Resource.join_dataset_with_resource()
    |> DB.ResourceHistory.join_resource_with_latest_resource_history()
    |> where([resource: r], r.format == "NeTEx")
    |> select([resource_history: rh], rh)
  end

  def validate_resource_history(resource_history_id) do
    %{
      "force_validation" => true,
      "validator" => Atom.to_string(Transport.Validators.NeTEx),
      "resource_history_id" => resource_history_id
    }
    |> Transport.Jobs.ResourceHistoryValidationJob.new()
  end
end

Script.query()
|> DB.Repo.all()
|> Enum.take(20)
|> Enum.map(&(&1.id |> Script.validate_resource_history()))
|> Oban.insert_all()
|> Logger.info()

---

Voir #4153

[AntoineAugusti]

En lisant https://hexdocs.pm/oban/Oban.Worker.html#module-snoozing-jobs j'ai l'impression que max_attempts va être incrémenté et ne sera pas respecté.

C'est ce qu'on souhaite ?

[ptitfred]

Damned, bien vu.

[ptitfred]

Pour l'instant ma conclusion c'est que je peux pas proprement tester ce comportement...

[ptitfred]

J'ai testé manuellement le comportement. Les helpers d'Oban n'émulent pas le snoozing.

[AntoineAugusti]

C'est suffisant pour de gros fichiers ? On peut suivre le nombre de timeout en dehors de oban_jobs qui a une rétention de seulement 24h ?

[ptitfred]

Le commentaire indique 1h de timeout global, c'est en réalité quelques secondes de moins, mais l'ordre de grandeur est bien celui-là.

C'est suffisant pour de gros fichiers ?

Je pense qu'1h est généreux et qu'on ne devrait pas avoir de cas pathologique qui prennent autant de temps. Cependant j'imagine qu'il pourrait y avoir de la contention sur leur plateforme si on envoie toutes les ressources en même temps.

On peut suivre le nombre de timeout en dehors de oban_jobs qui a une rétention de seulement 24h ?

Je ne sais pas comment te répondre. Je ne suis pas sûr que la rétention de 24h soit rédhibitoire si l'on timeout bien au bout d'1h.

[AntoineAugusti]

A-t-on besoin de voir ces logs en prod ? Sinon passer au niveau debug ?

[AntoineAugusti]

Je pense avoir la réponse à ma question précédente.

Le seul moyen de suivre les timeouts serait de regarder les logs d'erreurs en prod, on n'a pas de stockage de ceci en BDD.

[ptitfred]

En effet. Je n'ai pas de bonne réponse à te faire sur ce point.

[AntoineAugusti]

Faudrait-il ajouter du unique pour éviter plusieurs exécutions pour une même validation/resource history ?

C'est possible d'avoir ce job ajouté plusieurs fois ?

[ptitfred]

Je vais étudier ça.

[ptitfred]

J'ai ajouté un unique: [fields: [:worker, :args]]

[AntoineAugusti]

Ça me semble bien, merci pour la prise en compte de mes commentaires 🙏

Comme discuté en DM, OK pour merger avant les vacances, en début de journée de travail en vérifiant les performances et rollback en cas de problème d'exploitation.

Pour le suivi des timeouts/temps d'exécution, peut-être utiliser des compteurs AppSignal ? #4137