[Doctolib] Vérifier les slots avec /appointments.json

[DavidLibeau]

Sur Doctolib, des slots peuvent apparaitre sur la route /availabilities.json alors qu'ils n'existent pas réellement. Le front Doctolib vérifie cela avec une requête sur /appointments.json lors d'un clic sur un slot. Le scrapper devrait aussi faire cette vérification.

Voici un exemple de requête :

curl 'https://www.doctolib.fr/appointments.json'  -H 'content-type: application/json; charset=utf-8' --data-raw '{"agenda_ids":"450…-449…-449…","practice_ids":[180…],"appointment":{"start_date":"2021-05-19T14:30:00.000+02:00","visit_motive_ids":"2746…","profile_id":264…,"source_action":"profile"}}'

[grubounet]

Bonjour, est il possible de nous donner des centres pour lesquels les slots doctolib apparaissent sur availabilities.json alors qu'ils n'existent pas réellement ?

Merci de votre aide !

[DavidLibeau]

J'en ai vu sur plusieurs centres et apparemment c'est fréquent. Exemple ici : https://www.doctolib.fr/vaccination-covid-19/saint-saulve/centre-de-vaccination-covid-19-groupe-elsan ou là https://www.doctolib.fr/vaccination-covid-19/mirande/centre-de-vaccination-covid-19-cd-32-gers?highlight%5Bspeciality_ids%5D%5B%5D=5494&pid=practice-166214 ou https://www.doctolib.fr/vaccination-covid-19/valenciennes/centre-vaccination?highlight%5Bspeciality_ids%5D%5B%5D=5494

[Benvii]

Ça voudrait dire une requête pour chaque créneau, ça risque d'être énorme en terme de volume de requêtes.

Les rdv remontés par /availabilities.json sont normalement dispo, j'ai pas réussi à trouvé d'exemple non dispo, en revanche nos requêtes vers /availabilities.json différent de celles faites par le front de doctolib et référence des rdv non accessibles via le front de doctolib cf #512 si vous tombez sur ce genre de cas je suis preneur.

[DavidLibeau]

Pourtant j'en trouve plutôt facilement, voici un exemple actuellement : https://www.doctolib.fr/vaccination-covid-19/seine-et-marne/grand-centre-de-vaccination-covid-19-disney-village?highlight%5Bspeciality_ids%5D%5B%5D=5494

[Noezor]

D'accord avec @Benvii , cela fait beaucoup trop de requêtes à doctolib, surtout si on veut remonter + que 1 créneau. On est quand même très tributaires de doctolib. Si on x50 nos requêtes, ils vont nous cache et VMD sera inutile.
Je préfère garder la solution de @Benvii .

[DavidLibeau]

Oui, ça peut potentiellement faire beaucoup de requêtes si on souhaite vérifier chaque rendez-vous, mais on peut imaginer de ne pas le faire pour tous les rendez-vous. Une version très minimale pourrait être de vérifier que le premier rendez-vous uniquement si celui-ci est entre 0 et J+7.
Pour moi, on manque d'information sur l'impact de ces rendez-vous bloqués. Si ça se trouve, ça ne correspond qu'à un bug temporaire sur quelques centres… mais moi ce que j'ai vu sur un centre, c'est une centaine de rdv bloqués pendant plusieurs jours, ce qui me semble très problématique. Ainsi, il faut d'abord estimer l'impact avant de prendre une décision.

J'ai pas compris c'était quoi la solution de @Benvii. Par ailleurs, je n'ai pas compris non plus l'issue #512 qui a été citée.

[Benvii]

Après relecture il n'y a pas forcément de lien avec #512 puisqu'on parle d'un bug coté doctolib qui lui même sur la page du centre listerait des créneaux comme disponibles alors que lorsqu'on clique dessus ils ne le sont pas si j'ai bien compris ? Désolé pour la confusion qu'a pu apporter le #512

En phase avec @DavidLibeau il serait intéressant d'évaluer l'impact, je pense qu'on peut le scripter facilement : en utilisant le slot_list puis ajouter une method/filtrer qui pour chaque slot va vérifier la réelle dispo via /appointments.json comparer le résultat au appointment_count on peut commencer par le centre mentionné ici, l'étendre à un département (si on se fait pas ban par doctolib) et poster les résultats ici.

En revanche, même si on constate quelque chose j'ai peur qu'on puisse difficilement faire quelque chose, car on est clairement dans une stratégie de réductions des requêtes vers doctolib (dans les échanges avec eux) au mieux on peut leur remonter ce point si les chiffres sont alarmants.

[Benvii]

hello @DavidLibeau j'ai fait le test sur ce centre de valenciennes que tu as mentionné, j'ai bien réussi au bout de quelques exécutions à avoir un {'error': 'unavailable_slot'} mais uniquement sur le tout premier créneau disponible, quelques secondes après en relance mon script il avait disparu et plus d'erreur. Tous les autres créneaux sont bien remontés comme valide au POST appointments.json

J'ai également lancé mon script sur :

• saint-saulve : aucun créneau invalide
• mirande : aucun créneau invalide
• seine-et-marne - disney-village : aucun créneau invalide

Voir les warning dans les logs ici : https://pastebin.com/2HLEr5vy
Le code exécuté : https://github.com/Benvii/vitemadose/tree/502_doctolib_check_slot_with_appointments

Par conséquent, n'ayant pas constaté de problème flagrant sur les centres mentionné (hormis 1 premier créneau) ce qui ne me semble pas choquant, je vois pas matière à alourdir le nombre de requêtes du scraper pour un problème vraisemblablement mineur.

[JulienRobberechts]

Bonjour,
Je suis à la base un utilisateur mais j'ai eu ce problème hier et ça m'a rendu fou.
Je suis aussi dev mais débutant Python et sur ce projet.

Ce bug Doctolib est particulièrement vrai sur le rdv de deuxième dose affichant une notification "rdv non disponible" et demandant de saisir à nouveau le créneau de la première dose. On rentre dans une boucle infernal ou on doit tester chaque créneaux et noter sur un papier ceux déjà testé (Je n'imagine pas mes parents faire cela). Hier soir par exemple AUCUN des 2eme créneaux n'étaient dispo donc impossible de prendre RDV. En revanche ce matin à 5h tous les créneaux semblaient dispo. Je fais l’hypothèse que Doctolib fait une 2eme vérification et qu'au cours de la journée le cache est de plus en plus faux (voir même 0 dispo le soir).

Sur la solution je suis d'accord que c'est lourd de faire ainsi (POST https://www.doctolib.fr/appointments.json) mais si Doctolib ne fait pas correctement le boulot c'est au scraper d'apporter une solution effective pour permettre au gens de savoir quels créneaux sont vraiment dispo dans l'interface Doctolib et surtout en fin de journée. Je voulais faire un robot pour le faire mais vous le ferrez mieux que moi.

💡 On pourrait ne tester qu'un créneau par centre. Si il est bon on peux certifier qu'a telle heure il y en avait au moins un et l'afficher en info. Si il est pas valide on peut certifier qu'on a un problème potentiel sur ce centre.

Centre testé : https://www.doctolib.fr/vaccination-covid-19/poissy/centre-de-vaccination-de-poissy?pid=practice-163036

[DavidLibeau]

Merci pour le retour @JulienRobberechts. Le problème semble être rencontré par pas mal de gens, mais ça reste difficilement quantifiable.
Je vais essayer de faire un test sur un plus grand échantillon quand j'ai 5 minutes. C'est aussi problématique sur le compte total des rendez-vous disponibles. Il faut rappeler que Doctolib c'est ~80% des rdv et centres sur ViteMaDose !

[DavidLibeau]

Voici les résultats de mes tests :

	Quantité
Centres avec erreur unavailable_slot sur le premier rdv	19
Centres avec premier rdv vérifié	323
Centres avec aucune disponibilité	221

Sur un échantillon pseudo-aléatoire correspondant à 10% du total des centres Doctolib (sélection faire sur l'id du tableau lorsque l'unité était 1), seulement le premier slot disponible a été testé avec la route /appointments.json.

Détails des résultats :
stats.json.zip

[JulienRobberechts]

Intéressant 👍
Donc si je comprend bien:

• cas 1 c'est l'erreur qui nous occupe de 1er rdv "fantôme" (2%)
• cas 2 c'est un cas ok. en tout cas sur le 1er rdv de la liste.
• cas 3 c'est un cas ok. il n'y a juste pas de place.
• cas 4 c'est pas bien clair pour moi l'origine du problème (19.6%)

bref il y a un chiffre d'erreur unavailable_slot de 2% sur le 1er rdv (par opposition au rappel).
mais dans le test on se rend compte que dans 19.6% des cas on arrive pas à vérifier !
C'est super ennuyeux ! Je ne sais pas si ces Error 500 sont rencontrés par les utilisateurs ou bien si c'est juste le scraper !

Il est aussi tout à fait possible que le nombre d'erreur (unavailable_slot et 500) augmente au court de la journée. A regarder.

Et pour rappel le problème plus ennuyeux encore pour l'utilisateur est que cet erreur unavailable_slot arrive sur le rappel.

[DavidLibeau]

Le cas 4, c'est possiblement mon code qui ne construit pas bien la requête mais c'est possible que ça soit aussi Doctolib qui bug ou autre. Il faut que je regarde de plus près pour tenter de ne plus avoir de cas 4 et des chiffres plus fiables.

Je vais mettre à jour les chiffres car c'est mon code qui n'est pas bon.

[JulienRobberechts]

Certains sur ce projet ont-ils une relation avec les équipes de Doctolib ? Car à la base il y a un gros bug dans l'interface de Doctolib tout simplement. Plutôt que de corriger leur problème (ce qui sera pas simple et pas transparent pour l'utilisateur) on peut tout simplement leur remonter (si ils écoutent les feedback).

[DavidLibeau]

Voilà, j'ai réussit à débugger mon code et supprimer la ligne "Centres avec problème pour vérifier (souvent erreur 500 sur la requête /appointments.json)" (c'est un peu chiant car Doctolib a plusieurs formats de réponse sur la route /availabilities.json`).

J'ai déjà remonté le bug à Doctolib.

[Noezor]

Cool, je peux close alors ? Je pense que j'avais un peu sous-estimé le problème

[DavidLibeau]

@Noezor Donc vous ne voulez rien faire sur le sujet ?

[JulienRobberechts]

@Noezor Je pense que tu as lu "j'ai réussi à débugger mon code" et tu t'ai dis c'est résolu mais @DavidLibeau ne parlais que du code d'investigation afin de cerner le problème ! On est loin d'avoir identifié la cause racine du problème et trouvé une solution !

Pour moi, c'est pas une issue à fermer. Il y a des difficultés avec Doctolib, même si on ne les traite pas immédiatement il ne faut pas renoncer ou faire comme s’il n'y avait pas de problème. On n’est pas payé au nombre d'issues ici 🤣

[DavidLibeau]

J'ai pu faire quelques tests sur l'ensemble des centres Doctolib :

	02/06 vers 18h	03/06 8h30	03/06 9h30	04/06 9h30
Centres avec erreur unavailable_slot sur le premier rdv	144	135	192	267
Centres avec premier rdv vérifié	4273	4358	4307	4467
Centres avec aucune disponibilité	3816	3696	3658	3628

J'ai aussi compté les rdv de ces centres. Attention, je ne teste que le premier rendez-vous pour chaque centre, et je compte tous les rendez-vous ici, mais je n'ai pas testé tous les rendez-vous.

	02/06 vers 18h	03/06 8h30	03/06 9h30	04/06 9h30
Rdv des centres avec erreur unavailable_slot sur le premier rdv	17644	12955	24806	102954
Rdv des centres avec premier rdv vérifié	303425	304559	285584	325445

[grubounet]

@Benvii a mis en place une série de modifications qui devraient améliorer grandement le soucis ! Je close donc

[DavidLibeau]

L'issue demande de vérifier la réelle présence d'un rendez-vous avec l'endpoint appointments.json et je ne trouve à aucun moment ces requêtes : https://github.com/CovidTrackerFr/vitemadose/search?q=appointments.json&type=code.

Est-il possible d'avoir un résumé de ce qui a été fait ? @Benvii