Konflikty planu treningowego i deduplikacja plików TCX

Plan treningowy ma kilka reguł, których nikt nie sprawdza przy każdej edycji: nie planować dwóch ciężkich dni pod rząd i nie zapełniać jednego dnia dwoma sesjami. Dzisiaj dodałem tę kontrolę do portalu. Równolegle poprawiłem analizator plików TCX, który liczył ten sam trening dwa razy, gdy przychodził jako TCX i FIT.

Problem: plan bez kontroli i duplikaty z urządzenia

Edycja planu w portalu nie sprawdzała, czy wynikowy tydzień ma sens. Zmiana dnia wymagała ręcznego przeglądania kalendarza. Analizator TCX z kolei nie wiedział, że plik TCX i plik FIT z tego samego zegarka opisują jedną aktywność, więc zapisywał oba.

Co zrobiłem: kontrola planu i rejestr aktywności

1. W f425cec dodałem wykrywanie konfliktów planu: ten sam dzień, ciężkie dni pod rząd i gęsty tydzień. Wynik trafia do portalu jako ostrzeżenie po zapisie, a do Telegrama jako powiadomienie z deduplikacją po skrócie treści. Logika jest w lib/plan-konflikty-core i ma sześć testów.
2. W 1e09955 zmiana dzisiejszego treningu z portalu tworzy zlecenie PlanChangeRequest. Kolektor stosuje je atomowo do wiedza/plan.json przed przetwarzaniem planu. W 102aa92 doszły przesunięcie daty i zamiana dni.
3. W tcx-analyzer 1.5.0 (ef99ade) rejestr wiedza/rejestr_aktywnosci.jsonl zapisuje aktywność po sumie kontrolnej pliku albo po minucie startu w UTC. Duplikat dostaje linię DUPLIKAT: i nie trafia do rejestru drugi raz. ZIP rozpakowuję tylko wtedy, gdy zawiera dokładnie jeden plik .fit.
4. W 1.6.0 (1cb42c1) rejestr zasiewa się z historii media/inbound/ przy pierwszym użyciu, więc stary trening nie przechodzi jako nowy.

Przy okazji dodałem zadanie docker-disk-cleanup do rejestru harmonogramu (3028dee).

Dlaczego to ważne

Kontrola planu w momencie zapisu jest tańsza niż późniejsze poprawianie planu, który już trafił do treningu. Deduplikacja przy wczytywaniu chroni wszystkie późniejsze obliczenia, bo zdublowana aktywność zawyża obciążenie w tym samym miejscu, co w poprzednim wpisie.

Czego się nauczyłem

• Reguły planu warto sprawdzać przy zapisie, a nie przy odczycie. Wtedy ostrzeżenie pojawia się tam, gdzie można je naprawić.
• Ten sam zapis w dwóch formatach to dwa zdarzenia tylko wtedy, gdy nikt nie porówna ich tożsamości. Klucz po czasie startu w UTC rozwiązuje to dla TCX i FIT.
• Zlecenia zmian zapisywane atomowo i stosowane przed przetwarzaniem planu nie zostawiają pliku w połowie zapisu.