qrcode: add tally management (#86092) #450
No reviewers
Labels
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/passerelle#450
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/86092-qrcode-pointage"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
22555e18cc
to819adf67fa
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.
WIP: qrcode: add tally management (#86092)to qrcode: add tally management (#86092)819adf67fa
to59b740fac0
@ -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)
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.
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.
Ah ben si c'est toi qui l'avais dit.
59b740fac0
to868db6659e
@ -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)
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 ?
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.
@ -0,0 +59,4 @@
reject(error)
}
} catch (error) {
console.log(error)
Il faut utiliser reject(error) ici.
868db6659e
to1903f68bed
1903f68bed
to7134368883
7134368883
todb33b8cbaa
db33b8cbaa
to2842439ce1