Open marthevienne opened 2 weeks ago
@SaboniAmine j'essaie de prendre en main l'issue et si je galère, je te contacte :)
Ca marche! Pour info, maintenant que la gestion du python path est plus simple avec uv et le venv associé, je pense qu'un script bash qui enchaîne les 3 scripts python avec la bonne gestion d'erreur est plus facile qu'auparavant :)
@SebM42 Je pense que c'est l'erreur que @njouanin a vu :
(.venv) (base) ➜ backend git:(main) ✗ python3 bloom/tasks/create_update_excursions_segments.py
/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pydantic/_migration.py:283: UserWarning: pydantic.generics:GenericModel
has been moved to pydantic.BaseModel
.
warnings.warn(f'{import_path}
has been moved to {new_location}
.')
[bloom INFO @ 21:20:17] DEBUT - Création / mise à jour des excursions et des segments
[bloom INFO @ 21:20:18] Lecture des nouvelles positions depuis le 2024-11-11 20:14:57.333136+00:00
[bloom INFO @ 21:20:18] 1028 nouvelles positions
[bloom INFO @ 21:20:29] Création des excursions
[bloom ERROR @ 21:20:29] Session rollback because of exception
Traceback (most recent call last):
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 413, in get_loc
return self._range.index(new_key)
^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 0 is not in range
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/Users/marthevienne/12_bloom/backend/bloom/infra/database/database_manager.py", line 32, in session yield session File "/Users/marthevienne/12_bloom/backend/bloom/tasks/create_update_excursions_segments.py", line 160, in run df_start.loc[-1] = df_start.loc[0]
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexing.py", line 1191, in __getitem__
return self._getitem_axis(maybe_callable, axis=axis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexing.py", line 1431, in _getitem_axis
return self._get_label(key, axis=axis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexing.py", line 1381, in _get_label
return self.obj.xs(label, axis=axis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/generic.py", line 4301, in xs
loc = index.get_loc(key)
^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 415, in get_loc
raise KeyError(key) from err
KeyError: 0
Traceback (most recent call last):
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 413, in get_loc
return self._range.index(new_key)
^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: 0 is not in range
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/marthevienne/12_bloom/backend/bloom/tasks/create_update_excursions_segments.py", line 375, in <module>
run()
File "/Users/marthevienne/12_bloom/backend/bloom/tasks/create_update_excursions_segments.py", line 160, in run
df_start.loc[-1] = df_start.loc[0]
~~~~~~~~~~~~^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexing.py", line 1191, in __getitem__
return self._getitem_axis(maybe_callable, axis=axis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexing.py", line 1431, in _getitem_axis
return self._get_label(key, axis=axis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexing.py", line 1381, in _get_label
return self.obj.xs(label, axis=axis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/generic.py", line 4301, in xs
loc = index.get_loc(key)
^^^^^^^^^^^^^^^^^^
File "/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 415, in get_loc
raise KeyError(key) from err
KeyError: 0
J'ai eu cette erreur pour le navire ID 1050 @SebM42.
@njouanin tu sais d'où ça vient ? Seb ne sait pas d'où ça peut venir.
J'ai essayé de cleaner les nouvelles positions mais ça ne fonctionne pas, j'ai 0 positions nettoyées alors que j'avais des nouvelles positions en base.
Problème dans les dates pour clean_positions :
(.venv) (base) ➜ backend git:(setup_cron) ✗ python3 bloom/tasks/clean_positions.py
/Users/marthevienne/12_bloom/backend/.venv/lib/python3.11/site-packages/pydantic/_migration.py:283: UserWarning: pydantic.generics:GenericModel
has been moved to pydantic.BaseModel
.
warnings.warn(f'{import_path}
has been moved to {new_location}
.')
[bloom INFO @ 13:12:47] DEBUT - Nettoyage des positions
[bloom INFO @ 13:12:50] Lecture des nouvelles positions de Spire en base
[bloom INFO @ 13:12:50] Traitement des positions entre le 2024-11-18 20:15:02.535425+00:00 et le 2024-11-25 20:15:02.535425+00:00
[bloom INFO @ 13:12:50] 0 nouvelles positions de Spire
[bloom INFO @ 13:13:05] Ecriture de 0 positions dans la table vessel_positions
[bloom INFO @ 13:13:05] FIN - Nettoyage des positions en 18.00s
Ok, j'ai compris d'où ça vient... J'ai effectivement lancé un clean_positions
avant que des nouvelles données Spire soient mises en base (j'avais attendu 1 min mais ça n'a pas suffit). Du coup, cette ligne-là a tout chamboulé :
max_created = max(batch["created_at"]) if len(batch) > 0 else batch_limit
Ok, j'ai modifié la date dans task_executions
pour traiter les nouvelles données Spire. C'est bon maintenant.
Je comprends mieux pourquoi vous aviez dit qu'il fallait empêcher le lancement des tâches si ça échoue avant.
Je vais regarder ce que je peux faire avec le flock et vous proposer une solution, j'ai pris notes de ce que vous m'avez dit sur Slack.
Pour le plantage, c'est pas évident à trouver... j'ai l'impression que dans certains cas il y a des trous dans les positions remontées par spire. De ce que j'ai constaté à chaque fois, il suffit d'attendre le passage suivant sur traitement spire (15 minutes) pour relancer clean_positions. Dès qu'il y a un peu de profondeur à traiter il n'y a plus de pb apparemment.
je regarderai d ou peut provenir cette issue vendredi, j ai quelques pistes en tete à explorer
Il faut exécuter (toutes les 15 minutes) successivement et dans cet ordre les traitements:
On peut mettre ça dans un shell et programmer un cron toutes les 15 minutes. Peut-être entouré d'un flock pour éviter que le script se relance s'il est encore encore en cours au bout de 15 minutes.
Si un des scripts est interrompu pour n'importe quelle raison, aucun autre traitement futur ne doit être lancé.