eddy/wwebjs-api

Watch

Fork 0

feat: auto-mark managed group as seen on Eddy session #2

New issue

Open

opened 2026-08-24 16:45:05 +02:00 by eddy · 1 comment

eddy commented

2026-08-24 16:45:05 +02:00

Owner

Doel

Markeer inkomende berichten in één specifieke beheergroep automatisch als gelezen op de Eddy-sessie, zonder andere chats te beïnvloeden.

Context

De groep Dienst opvragen EdGPT-EBS is voor de Eddy-sessie inhoudelijk niet relevant, maar moet wel handmatig zichtbaar blijven voor beheer. Ongelezen berichten stapelen zich nu op. De gewenste scope is daarom een automatische read-markering zodra Eddy een bericht uit deze groep ontvangt.

Gewenst gedrag

Alleen sessie Eddy.
Alleen chat/group JID 120363407613652082@g.us (Dienst opvragen EdGPT-EBS).
Markeer de chat zo snel mogelijk als gelezen na ontvangst van een bericht.
Laat de bestaande message-webhook en overige chats ongewijzigd functioneren.
Een fout in sendSeen mag de webhookverwerking of de sessie niet laten falen.
Geen Appium/ADB-fallback; dit hoort volledig in de WWebJS-laag.
Geen wijziging aan de publieke sendSeen-API vereist.

Mogelijke implementatierichting

Voeg in de sessie-eventregistratie een specifieke, niet-blokkerende hook toe rond het bestaande message-event:

if (sessionId === "Eddy" && message.from === "120363407613652082@g.us") {
    client.getChatById(message.from)
        .then((chat) => chat.sendSeen())
        .catch((error) => logger.warn({ sessionId, error }, "Failed to mark managed chat as seen"));
}

De bestaande webhook moet onafhankelijk doorgaan. Verifieer vóór implementatie de exacte eventvelden (message.from, sessie-ID), de chat lookup en de bestaande WWeb-version signature.

Acceptatiecriteria

Bericht in deze groep op Eddy → chat wordt gelezen gemarkeerd.
Bericht in deze groep op EdGpt → geen extra automatische read-hook.
Bericht in een andere chat op Eddy → geen automatische read-hook.
sendSeen-fout → message-event/webhook blijft functioneren en fout wordt gelogd.
Geen Appium-container of Android-notifier nodig.
Bestaande publieke API en overige sessies blijven ongewijzigd.

## Doel Markeer inkomende berichten in één specifieke beheergroep automatisch als gelezen op de `Eddy`-sessie, zonder andere chats te beïnvloeden. ### Context De groep `Dienst opvragen EdGPT-EBS` is voor de `Eddy`-sessie inhoudelijk niet relevant, maar moet wel handmatig zichtbaar blijven voor beheer. Ongelezen berichten stapelen zich nu op. De gewenste scope is daarom een automatische read-markering zodra `Eddy` een bericht uit deze groep ontvangt. ### Gewenst gedrag - Alleen sessie `Eddy`. - Alleen chat/group JID `120363407613652082@g.us` (`Dienst opvragen EdGPT-EBS`). - Markeer de chat zo snel mogelijk als gelezen na ontvangst van een bericht. - Laat de bestaande message-webhook en overige chats ongewijzigd functioneren. - Een fout in `sendSeen` mag de webhookverwerking of de sessie niet laten falen. - Geen Appium/ADB-fallback; dit hoort volledig in de WWebJS-laag. - Geen wijziging aan de publieke `sendSeen`-API vereist. ### Mogelijke implementatierichting Voeg in de sessie-eventregistratie een specifieke, niet-blokkerende hook toe rond het bestaande `message`-event: ```js if (sessionId === "Eddy" && message.from === "120363407613652082@g.us") { client.getChatById(message.from) .then((chat) => chat.sendSeen()) .catch((error) => logger.warn({ sessionId, error }, "Failed to mark managed chat as seen")); } ``` De bestaande webhook moet onafhankelijk doorgaan. Verifieer vóór implementatie de exacte eventvelden (`message.from`, sessie-ID), de chat lookup en de bestaande WWeb-version signature. ### Acceptatiecriteria 1. Bericht in deze groep op `Eddy` → chat wordt gelezen gemarkeerd. 2. Bericht in deze groep op `EdGpt` → geen extra automatische read-hook. 3. Bericht in een andere chat op `Eddy` → geen automatische read-hook. 4. `sendSeen`-fout → message-event/webhook blijft functioneren en fout wordt gelogd. 5. Geen Appium-container of Android-notifier nodig. 6. Bestaande publieke API en overige sessies blijven ongewijzigd.

eddy commented

2026-08-24 17:04:07 +02:00

Author

Owner

Additional findings and expected direction:

WhatsApp Web marks a chat/group as read when the chat is opened through the normal Web UI. For this use case, a reliable solution may therefore avoid the unstable internal sendSeen primitives entirely:

message event on Eddy
→ verify the target group JID
→ return to a defined WhatsApp Web chats-overview state
→ open the target group through the normal UI
→ wait until the group is loaded/read
→ return to the defined chats-overview state

The target is specifically session Eddy and group 120363407613652082@g.us (Dienst opvragen EdGPT-EBS). Other sessions and chats must remain unaffected.

Expected behavior:

opening the target group should cause WhatsApp Web itself to mark its messages read;
the helper should return to a stable chats-overview state afterward;
UI actions must be serialized/coalesced and bounded by a timeout;
an automated read-marking failure must not break the existing message webhook or session;
no Appium/ADB fallback is required for this solution;
the public sendSeen API need not change unless the helper is later exposed explicitly.

Implementation direction:

Add a small browser-side helper in the WWebJS layer, not a broad global sendSeen replacement.
Validate the chat by JID before navigating.
Do not rely on fixed screen coordinates or browser history alone; use current WhatsApp Web selectors/state.
Confirm the target group is loaded before returning to the overview.
Test that subsequent incoming events still work and that the browser does not remain in an unintended chat.

This is a practical UI-based direction for the managed-group use case, not a claim that it replaces the general WhatsApp Web read-receipt API for every chat/version.

Additional findings and expected direction: WhatsApp Web marks a chat/group as read when the chat is opened through the normal Web UI. For this use case, a reliable solution may therefore avoid the unstable internal `sendSeen` primitives entirely: ```text message event on Eddy → verify the target group JID → return to a defined WhatsApp Web chats-overview state → open the target group through the normal UI → wait until the group is loaded/read → return to the defined chats-overview state ``` The target is specifically session `Eddy` and group `120363407613652082@g.us` (`Dienst opvragen EdGPT-EBS`). Other sessions and chats must remain unaffected. Expected behavior: - opening the target group should cause WhatsApp Web itself to mark its messages read; - the helper should return to a stable chats-overview state afterward; - UI actions must be serialized/coalesced and bounded by a timeout; - an automated read-marking failure must not break the existing message webhook or session; - no Appium/ADB fallback is required for this solution; - the public `sendSeen` API need not change unless the helper is later exposed explicitly. Implementation direction: - Add a small browser-side helper in the WWebJS layer, not a broad global `sendSeen` replacement. - Validate the chat by JID before navigating. - Do not rely on fixed screen coordinates or browser history alone; use current WhatsApp Web selectors/state. - Confirm the target group is loaded before returning to the overview. - Test that subsequent incoming events still work and that the browser does not remain in an unintended chat. This is a practical UI-based direction for the managed-group use case, not a claim that it replaces the general WhatsApp Web read-receipt API for every chat/version.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

eddy/wwebjs-api#2

No description provided.

Rows
Columns