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

Companion ACKs a direct message that it then drops when the offline queue is full

Abierto
  • ¿Algo no está bien?
#3,518 1 comentario 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
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c
Área
backend, networking

Línea de trabajo

Start with addToOfflineQueue() in examples/companion_radio/MyMesh.cpp (lines 224–246) and the ACK path in BaseChatMesh::onPeerDataRecv() in src/helpers/BaseChatMesh.cpp (around lines 239–254). Trace how onMessageRecv() handles direct messages when the queue is full and how that result controls ACKs. Done when a dropped message is not acknowledged, with queue eviction behavior clarified if implementing the broader suggestion.

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

Descripción

When the companion's offline queue is full (OFFLINE_QUEUE_SIZE, default 16) and holds no channel messages, addToOfflineQueue() drops the incoming direct message (examples/companion_radio/MyMesh.cpp, dev, lines 224-246). BaseChatMesh::onPeerDataRecv() still sends the ACK afterwards (src/helpers/BaseChatMesh.cpp, around lines 239-254), because onMessageRecv() returns void.

Result: the sender sees the message as delivered, but it never reaches the app. This happens when the phone is disconnected for a while and more than 16 DMs arrive.

Suggested fix, in increasing scope:

  1. Let onMessageRecv() return whether the message was stored, and only ACK when it was. The sender then retries later, as it would for an unreachable node.
  2. When the queue is full of DMs, evict other non-DM frames first, and only refuse (no ACK) as a last resort.
  3. Optionally, keep the offline queue in flash so a reboot or empty battery does not lose ACKed messages.

Related: #1834 (failed delivery shown but message received) is the inverse case; this one reports success while the message is lost.

Lenguaje dominante
C
Estrellas
3.9k
Forks
1.5k
Merge medio
1 d 3 h
PR fusionados (30 d)
24

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 meshcore-dev/MeshCore

Todos los issues de meshcore-dev/MeshCore

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.