Open thbar opened 4 months ago
Stratégies possibles pour mitiger, pour mémoire:
assert_difference
dans ces 3 tests (le plus solide)metrics
en démarrage des tests de apps/transport
, fonctionnera aussiapps/unlock
(plus compliqué à mettre en oeuvre à mon avis)
Ticket pour prévenir un "WTF" pour celui qui tombera dessus (c'est initialement très confusant), sans urgence immédiate à traiter, mais à améliorer dans le temps.
En travaillant sur:
3839
et en particulier en débuggant la télémétrie, je suis tombé sur l'os suivant: si un test de
apps/unlock
génère un évènement de télémétrie lié aux métriques à un moment où les handlers ne sont pas déconnectés d'Ecto (handlers qui ne sont pas connus deapps/unlock
mais sont activés au boot général), un métrique sera inséré en base (comme attendu), mais ce métrique génèrera alors des failures (3 répertoriées actuellement) liées à un couplage trop fort de tests deapps/transport
sur le contenu de la base métriques.Ce couplage trop fort nous posera d'autres problèmes, et pourrait être réglé avec un pattern du type
assert_difference
(voir https://apidock.com/rails/v7.1.3.2/ActiveSupport/Testing/Assertions/assert_difference) plutôt qu'une comparaison brute par égalité.Je vois 3 failures pour le moment:
Pour reproduire:
Unlock.ControllerTest
, commenter les appels àtelemetry.detach
ecto.drop ecto.create
, ou bien drop des lignes dansmetrics
), donc un état bloquant.