notification-acks: Track clients in memory and give up when they stop checking in
Los mantenedores suelen responder en 1 día
@t-obr-iv ya está trabajando en esto.
Desde el 18/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Exploring
scylla-server keeps an in-memory queue of numbered notifications for each client ID. The client reports the last number it received, and the server resends the rest. The server, not the socket, decides when a client is gone, and then drops its queue and subscriptions. The client's last-number report doubles as a regular check-in; missing several means the client is gone, whatever the socket's state.
Hypothesis
Check-ins catch a dead client faster than socket state, including connections that look open but are not, so the server stops queueing for dead clients sooner.
Context transfer
SUMMARY
#845: make sure a Rule's notification is actually received. The notification-acks spikes try different ways for the client to confirm what it got, so scylla-server can resend what it missed, for example after a Wi-Fi drop at the track or a laptop sleeping.
CONTEXT
- A Rule is a user-defined condition on a topic's values (e.g. a > 100) that notifies its subscribers when it matches. Logic in scylla-server/src/rule_structs.rs; a Rule fires after its debounce, then waits a fixed 5s cooldown.
- Delivery: handle_rule_processing in scylla-server/src/socket_handler.rs emits the rule_notify Socket.IO event (RuleNotification: id, topic, values, time) to the subscribing client, inline in the socket delivery loop. Nothing confirms the browser received it; a successful emit only means it was queued on the socket (buffer of 4096, shared with telemetry).
- RuleNotification.id is the Rule's ID, not unique per firing.
- If the subscribing client is not connected when a Rule fires, the notification is dropped and the client's subscriptions are deleted (socket_handler.rs, around lines 321-339). A failed emit is only logged.
- Clients identify with a client ID kept in localStorage (angular-client/src/services/socket.service.ts) and sent as the clientId query parameter when the socket connects (and as the x-client-id header on REST calls).
- Socket.IO is configured in scylla-server/src/main.rs: ping_timeout 5s, default ping_interval 25s, ack_timeout 1500ms. A silently dead connection can go unnoticed for up to about 30s; notifications sent in that window count as sent.
- Fired notifications are not stored on the server and there is no endpoint to fetch them. The client's notification log (angular-client/src/services/notification-log.service.ts) is in browser memory and cleared on reload.
- Server: socketioxide 0.18.7. Client: socket.io-client 4.7. socketioxide has no connection state recovery (Node Socket.IO's built-in replay of missed messages).
- Related: #801 moves rule processing off the delivery loop. Tests: scylla-server/tests/rule_structs_test.rs; nothing covers socket_handler.rs.
- Notifications carry no sequence number today, and the client does not send anything back when it receives one.
- Today the first notification that cannot be delivered deletes all of that client's subscriptions, plus any Rules left with no subscribers.
- The client reconnects automatically (socket.io-client default) and sends the same client ID each time it connects.
- Lenguaje dominante
- TypeScript
- Estrellas
- 5
- Forks
- 1
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 35
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Northeastern-Electric-Racing/Argos
-
Remove the landing pagePosiblemente ocupada @Idontknow0487 la tomó hace 16 días. Abiertoby: ai-assisted frontend good-for: new-member spike
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Northeastern-Electric-Racing/Argos#847 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Delete the unused Angular client componentsPosiblemente ocupada @bracyw la tomó hoy. Abiertoby: ai dev work frontend
Northeastern-Electric-Racing/Argos#962 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Replace PrimeNG with Tailwind and our own componentsPosiblemente ocupada @bracyw la tomó hace 1 día. Abiertoby: ai dev work frontend
Northeastern-Electric-Racing/Argos#960 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Show Charging page faults from the fault feedPosiblemente ocupada @SimeonChenchev1 la tomó hace 2 días. Abiertoby: ai-assisted dev work frontend
Northeastern-Electric-Racing/Argos#959 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
by: ai dev work frontend
Northeastern-Electric-Racing/Argos#940 ·
Los mantenedores suelen responder en 1 día
Todos los issues de Northeastern-Electric-Racing/Argos
Issues similares
-
Recording drops clicks on links, filters and checkboxes that share a form with a search fieldPosiblemente ocupada @columbia11 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Tencent/BrowserSkill#657 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
Los mantenedores suelen responder en 2 días
-
Choosing a folder while continuing an Antigravity session submits a history fork the runtime rejectsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 87/100
-
ai-handle
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
nextlevelbuilder/dewee-web-v2#138 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
NEARBuilders/citynode.app#512 ·
Los mantenedores suelen responder en 1 día