qrcode: add tally management (#86092) #450

Merged
csechet merged 2 commits from wip/86092-qrcode-pointage into main 2024-02-13 14:30:27 +01:00
Owner
No description provided.
csechet added 1 commit 2024-01-29 08:59:02 +01:00
gitea/passerelle/pipeline/head There was a failure building this commit Details
22555e18cc
qrcode: add tally management (#86092)
csechet force-pushed wip/86092-qrcode-pointage from 22555e18cc to 819adf67fa 2024-02-12 10:52:32 +01:00 Compare
Author
Owner

Benj :

J'ai fait un peu différent de ce que tu proposes dans le ticket : je me suis arrangé pour que le ServiceWorker intercepte les requêtes envoyées à Passerelle, et réponde avec le même format. Ça permet de faire en sorte que tout fonctionne, même si c'est plus lent, si le ServiceWorker ne fonctionne pas, pour une raison ou une autre (et il y a beaucoup de raison potentielles pour qu'il ne démarre pas)

Les service workers sont terminés au bout de 30 secondes d'inactivités sur Chrome & Firefox (et probablement sur Safari aussi), d'où l'envoi du message de refresh toutes les 15 secondes. On peut allonger la période, mais pas au delà de 30 secondes.

Après de la bonne galère, je n'ai pas trouvé comment tester le service Worker, sans embarquer Playwright ou usine à gaz équivalente. Je suis preneur d'une solution si tu en as une.

J'ai testé sur mon téléphone, le SW set démarré et envoie les demandes de rafraîchissement à Passerelle, mais n'intercepte pas les requêtes à l'API. Je pense que c'est dû au header Service-Worker-Allowed qui ne doit pas être transmis par le proxy de Browser-Sync que j'utilise pour tester, mais il faudrait tester en situation réelle sur la recette.

Benj : J'ai fait un peu différent de ce que tu proposes dans le ticket : je me suis arrangé pour que le ServiceWorker intercepte les requêtes envoyées à Passerelle, et réponde avec le même format. Ça permet de faire en sorte que tout fonctionne, même si c'est plus lent, si le ServiceWorker ne fonctionne pas, pour une raison ou une autre (et il y a beaucoup de raison potentielles pour qu'il ne démarre pas) Les service workers sont terminés au bout de 30 secondes d'inactivités sur Chrome & Firefox (et probablement sur Safari aussi), d'où l'envoi du message de refresh toutes les 15 secondes. On peut allonger la période, mais pas au delà de 30 secondes. Après de la bonne galère, je n'ai pas trouvé comment tester le service Worker, sans embarquer Playwright ou usine à gaz équivalente. Je suis preneur d'une solution si tu en as une. J'ai testé sur mon téléphone, le SW set démarré et envoie les demandes de rafraîchissement à Passerelle, mais n'intercepte pas les requêtes à l'API. Je pense que c'est dû au header Service-Worker-Allowed qui ne doit pas être transmis par le proxy de Browser-Sync que j'utilise pour tester, mais il faudrait tester en situation réelle sur la recette.
csechet changed title from WIP: qrcode: add tally management (#86092) to qrcode: add tally management (#86092) 2024-02-12 10:59:45 +01:00
csechet force-pushed wip/86092-qrcode-pointage from 819adf67fa to 59b740fac0 2024-02-12 11:19:32 +01:00 Compare
bdauvergne reviewed 2024-02-12 13:22:37 +01:00
@ -314,0 +373,4 @@
if since_timestamp == 0:
since = now - timedelta(days=1)
elif since_timestamp is not None:
since = datetime.fromtimestamp(since_timestamp, timezone.utc)
Owner

J'enlèverai 1 bonne minute, entre les décalage possibles entre l'heure des noeuds et le temps que pourrait mettre postgres à commiter en cas de charge, le fait de récupérer quelques évènements en trop n'est pas bien grave.

J'enlèverai 1 bonne minute, entre les décalage possibles entre l'heure des noeuds et le temps que pourrait mettre postgres à commiter en cas de charge, le fait de récupérer quelques évènements en trop n'est pas bien grave.
Author
Owner

En relisant, je me demande pourquoi j'ai fait :

since = now - timedelta(days=1)

Sur la ligne précédente : il faut renvoyer tous les évènnements, pas ceux vieux d'un jour.

En relisant, je me demande pourquoi j'ai fait : `since = now - timedelta(days=1)` Sur la ligne précédente : il faut renvoyer tous les évènnements, pas ceux vieux d'un jour.
Author
Owner

Ah ben si c'est toi qui l'avais dit.

Ah ben si c'est toi qui l'avais dit.
csechet marked this conversation as resolved
csechet force-pushed wip/86092-qrcode-pointage from 59b740fac0 to 868db6659e 2024-02-12 15:21:51 +01:00 Compare
bdauvergne reviewed 2024-02-13 11:33:57 +01:00
@ -0,0 +144,4 @@
// with InactiveTransactionError.
const transaction = db.transaction([_EVENTS], 'readwrite')
const tallyEventStore = transaction.objectStore(_EVENTS)
const request = overwrite ? tallyEventStore.put(tallyEvent) : tallyEventStore.add(tallyEvent)
Owner

J'ai un peu du mal avec l'API IndexedDb, il semble que ça fasse beaucoup de choses implicitement. De ce que je comprends ici, avec overwrite=true on va recevoir les évènements déjà pointés qui ne contiennent donc pas pending=1 comme plus haut l. 73, et ça va écraser l'enregistrement existant retourvé via la clé "certificate" parce qu'on a déclaré cette clé unique ?

J'ai un peu du mal avec l'API IndexedDb, il semble que ça fasse beaucoup de choses implicitement. De ce que je comprends ici, avec overwrite=true on va recevoir les évènements déjà pointés qui ne contiennent donc pas pending=1 comme plus haut l. 73, et ça va écraser l'enregistrement existant retourvé via la clé "certificate" parce qu'on a déclaré cette clé unique ?
Author
Owner

Oui c'est tout à fait ça. J'aurai pu ajouter pending=0 et faire explicitement une recherche des évènements qui ont pending=1 ligne 162, mais les indexes retournent uniquement les objets qui ont une valeur pour la clé indexée : ne pas mettre de valeur dans le champ pending suffit à les écarter de ce qui est retourné ligne 162.

Oui c'est tout à fait ça. J'aurai pu ajouter pending=0 et faire explicitement une recherche des évènements qui ont pending=1 ligne 162, mais les indexes retournent uniquement les objets qui ont une valeur pour la clé indexée : ne pas mettre de valeur dans le champ pending suffit à les écarter de ce qui est retourné ligne 162.
bdauvergne approved these changes 2024-02-13 11:57:30 +01:00
csechet reviewed 2024-02-13 11:57:59 +01:00
@ -0,0 +59,4 @@
reject(error)
}
} catch (error) {
console.log(error)
Author
Owner

Il faut utiliser reject(error) ici.

Il faut utiliser reject(error) ici.
csechet force-pushed wip/86092-qrcode-pointage from 868db6659e to 1903f68bed 2024-02-13 12:05:44 +01:00 Compare
csechet force-pushed wip/86092-qrcode-pointage from 1903f68bed to 7134368883 2024-02-13 12:19:46 +01:00 Compare
csechet force-pushed wip/86092-qrcode-pointage from 7134368883 to db33b8cbaa 2024-02-13 12:23:02 +01:00 Compare
csechet force-pushed wip/86092-qrcode-pointage from db33b8cbaa to 2842439ce1 2024-02-13 13:17:34 +01:00 Compare
csechet merged commit 2842439ce1 into main 2024-02-13 14:30:27 +01:00
csechet deleted branch wip/86092-qrcode-pointage 2024-02-13 14:30:27 +01:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/passerelle#450
No description provided.