API des membres + Cache = KBOOOM ! #2727
Comments
SpaceFox
added
the
Bloquant
GerardPaligot
changed the title
|
Les échecs des tests mentionnés par Travis sont cohérents avec le comportement actuel de l'API des membres en production. J'étais persuadé que le problème se situait sur les problèmes serveurs que nous avons eu avec OVH mais cette issue me fait douter. Donc nous semblons avoir un problème de cache avec la pagination (ici et en prod) mais, dans le code source, nous renseignons bien la pagination comme clé pour le cache. Je ne comprends donc pas pourquoi les tests échouent pour l'API des membres (et passent pour les tests de l'API des MPs au passage). |
|
Les tests chez moi passe pas non plus pour les mp, si on active le cache. On voit clairement d'après, les logs qu'il essaye toujours de comparer un résultat en cache (qui est de 10). On peut supposer que lors du test, il est passé par une méthode qui a insérer 10 membres et qu'il a fait une requête GET vers api-member-list. Le cache est créé avec les 10 réponses pour une période par défaut. Lors des appels suivant, il réutilise le cache d'ou les erreurs. |
|
Je permet de te ping @GerardPaligot pour avoir ton avis, il ont mis à jours la documentation de l'api et propose une solution pour invalider le cache. Si je résume la solution de la documentation, dans le Après la méthode associé qui nous permet de créé une clé de cache api_updated_at_timestamp qui représentera quand l'objet sera mis à jours. class UpdatedAtKeyBit(KeyBitBase):
def get_data(self, **kwargs):
key = 'api_updated_at_timestamp'
value = cache.get(key, None)
if not value:
value = datetime.datetime.utcnow()
cache.set(key, value=value)
return force_text(value)Pour invalider le cache quand on modifie un user par-exemple: post_save.connect(receiver=change_api_updated_at, sender=model)
def change_api_updated_at(sender=None, instance=None, *args, **kwargs):
cache.set('api_updated_at_timestamp', datetime.datetime.utcnow())La doc officielle est ici, c'est juste avant le paragraphe: Key constructor params. T'en pense quoi ? c'est un peu de boulot et ça manque un peu de finesse (on invalide tous alors qu'on a modifié un user seulement) mais je pense qu'on peut faire un truc plus fin. L'idée générale me plait bien ^^. |
|
Je ne comprends pas le rapport avec le problème de cette issue qui est lié à la pagination et dont la clé est renseignée en fait. |
|
Pour moi, c'est pas liés à la pagination. Je me permet de me citer:
|
|
C'est sans doute ce qu'il fait mais pour moi, il ne faut pas modifier le code source parce que nous savons pas comment le tester. Si les tests Django sont unitaires, le cache ne devrait pas subsister à travers les méthodes et toutes les données devraient être supprimées. Après, s'ils ne sont pas unitaires, il faut faire évoluer les tests en conséquence puisqu'ils ont été développé en partant du principe qu'ils étaient unitaires. |
|
Ok, je comprend tes arguments, ça me parait pertinent. |
|
Sur ce, on est finalement OK :) |
Bug découvert en tentant d'activer Memcached dans Travis (cf ce job) et parfaitement reproductible en local.
Quand on lance les tests avec Memcached d'activé, certains tests plantent. Tous sont des tests liés à l'API des membres.
Le fait de ne lancer que cette batterie de tests ou l'intégralité de la suite ne change rien.
Le fait d'utiliser les moteurs de cache suivants ne change rien et provoque les erreurs (settings de cache
CACHESdirectement repiqués dans la doc) (memcached est évidemment arrêté pour éviter les effets de bord lors des test avec les autres systèmes de cache)Par contre le moteur "Database caching" fonctionne (!) (et j'ai vérifié, il crée bien la table de cache en mode test).
Et évidemment "Dummy caching" fonctionne, puisque par définition il ne fait rien.
C'est bloquant parce que le cache est actif en prod -- il l'est déjà aujourd'hui, et il faut qu'on sache si c'est juste les tests qui sont incompatibles avec le cache (ce que je pense probable) ou si on a un truc foireux / qui va devenir foireux à la prochaine MEP.
Idées de tests :
Ceci devrait nous permettre de savoir si l'API est cassée ou si c'est "juste" les tests qui sont incompatibles avec le cache.
Logs sur les tests de l'API des membres, Debian 8, MySQL :
The text was updated successfully, but these errors were encountered: