Je rebondis sur ce sujet du coup, j’ai terminé la vérification pour la PR sur l’amélioration du recalcul du suivi de l’énergie. Je pense que tu peux review :
S’ensuivra la PR suivante qui ajoute du logging plus claire pour l’utilisateur, notamment pour voir ou en étaient les dernière tache lancées si jamais un redémarrage Gladys ou un problème était survenu pendant un recalcul (évitant de devoir refaire tout le recalcul …) :
Est-ce que tu pourrais décrire plus en détail ce que fait cette PR ?
Comme cela touche au core, ce sont des changements assez sensibles.
J’aimerais bien comprendre précisément le périmètre pour pouvoir évaluer correctement l’impact.
Lors du développement j’ai passé plusieurs mois sur la fiabilisation des calculs, et c’est vital pour moi que le calcul ne soit pas impacté
Tu as raison de demander le détail, je comprends tout à fait. Et si possible, je préférerais que tu le test également, en le laissant tourner à côté de ta prod por bien vérifier. C’est ce que j’ai fais pour bien évaluer le bon fonctionnement. Je n’ai pas trouvé de cas de figure où ça plante. Mais par exemple, je n’ai pas de zigbee énergie par exemple. Même si il n’y a aucune raison que ce soit différent, ça couvrirait l’ensemble.
Le diff global est gros (+3203 / -428), mais le périmètre fonctionnel que je vise dans cette PR est surtout celui-ci :
Recalcul ciblé (backend) sur plage de date / sélection de features
Ajout du recalcul par plage de dates pour :
le coût (calculate-cost-range)
la conso depuis index (calculate-consumption-from-index-range)
Les endpoints “from beginning” acceptent aussi maintenant une sélection de features (feature_selectors).
Validation des dates YYYY-MM-DD côté controller (avec BadParameters si format invalide).
Recalcul partiel sans casser le reste
Quand je recalcule une période, je purge uniquement les états dans la période (destroyStatesBetween) avant recomputation.
Quand il n’y a pas de date de fin, je garde le comportement “from start → now” (destroyStatesFrom).
Pour la conso depuis index, je restaure ENERGY_INDEX_LAST_PROCESSED en fin de traitement sur les recalculs partiels/sélectionnés pour éviter d’abîmer le curseur global.
Exécution en tâche de fond
Passage en wrapperDetached pour les recalculs longs (from beginning / range), pour renvoyer immédiatement un job_id.
Le front ne considère l’action OK que si un job_id est bien retourné.
Front (écran energy monitoring)
Ajout des champs date de début / date de fin (chaque champs est facultatifs).
Ajout de la sélection multiple de features à recalculer.
Si aucune feature n’est sélectionnée, confirmation explicite avant recalcul global.
Appel automatique des endpoints range si une date est fournie, sinon des endpoints from-beginning.
Ce que je n’ai pas touché dans le core de calcul
Je n’ai pas changé les formules de calcul des contrats (le moteur contracts.calculateCost reste le même).
Je n’ai pas changé la logique de base du delta d’index (la formule reste identique), j’ai surtout encadré le périmètre (sélecteurs, dates, purge ciblée, job handling).
Je n’ai :
ni changé les formules métier de calcul des contrats
ni le principe de delta d’index
ni la conversion d’unité qu’on avait mis en place dernièrement.
J’ai « seulement » modifié le périmètre d’entrée (features sélectionnées, plage de dates) et l’encadrement technique des recalculs (purge ciblée, jobs, API/front).
Et pour tout te dire, en début de semaine, j’ai faillis fermer les PR de ce sujet et t’écrire pour te dire que je te laissais la main sur ce sujet.
J’avais peur que ça te prenne plus de temps à review qu’à le faire toi même. Qu’en plus visuellement ça ne te convienne pas. Et que du coup tu aurais sûrement été mieux à le faire tel que tu le penses.
Mais je balance entre cette question et le fait qu’on soit quand meme quelques uns à être en attente. Et du fait que je vois bien que tu es occupé dans bien d’autres choses.
Alors je suis parti du posta de proposer, et que toi tu disposes. Et tu me donneras ton retour / ressenti.
