Review fleet reconciliation: what breaks while a gateway rebuilds its view

Ouverte
#412 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
backend

Piste de recherche

Start with the behavior described in #410, then trace how worker reports rebuild the gateway’s lease, device and request state and what requests see during that process. Resolve whether events and component installs are in scope. Done means a list of reconciliation findings, each marked accepted or paired with a proposed fix.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

feature:spec

Request: none

Problem

A gateway keeps an in-memory view of the fleet: which worker holds which lease, device and request. It rebuilds that view from what workers report. While it rebuilds — after a gateway restart, a worker reconnect, or a worker forgotten past retention — its view and the workers' truth can disagree. Nobody has reviewed, as a whole, what goes wrong in that window and who wins when the two disagree.

Known case

From #410 (caller-chosen lease IDs). After a gateway restart, the gateway has not yet heard from every worker. A new request with lease ID myid is granted on worker w2, while worker w1 still holds a lease myid from before the restart. When w1 reports, two workers hold myid.

What #410 does today: the first lease reported keeps myid. The gateway logs a warning and does not route to the second. Nobody can renew the second, so it expires at its TTL, holding a device until then.

What this issue asks for

A review of fleet reconciliation for problems of this kind, not only this case:

  • every piece of gateway state rebuilt from worker reports, and what a request sees while it is incomplete;
  • every clash between the gateway's view and a worker's truth, and which side wins;
  • for each, whether the current answer is acceptable or needs a fix.

The output is a list of findings, each with a proposed fix or "accepted". Fixes become their own tasks.

Open questions

  • Scope of the review: lease, device and request state only, or events and component installs too?

Written by an agent.

Langage dominant
TypeScript
Étoiles
621
Forks
30
Merge moyen
8 h 58 min
PR mergées (30 j)
472

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de callstackincubator/simlock

Toutes les issues de callstackincubator/simlock

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.