Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#412 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
15
Forks
1
Merge medio
9 h 6 min
PR fusionados (30 d)
138

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de callstackincubator/simlock

Todos los issues de callstackincubator/simlock

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.