feat(events): add isLatest and progress to messages.set event - #2260
Merged
DavidsonGomes merged 3 commits intoDec 5, 2025
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
- Add extra field to EmitData type for additional payload properties - Update EventManager and sendDataWebhook to support extra parameters - Update all event controllers (webhook, rabbitmq, sqs, websocket, pusher, kafka, nats) to include extra fields in payload - Pass isLatest and progress from Baileys messaging-history.set to messages.set webhook This allows consumers to know when the history sync is complete (isLatest=true) and track sync progress percentage.
Copy link
Copy Markdown
Contributor
Reviewer's GuideAdds support for passing arbitrary extra metadata through the event pipeline so that Baileys messaging-history.set events can expose isLatest and progress on the messages.set payload across all delivery mechanisms (webhook, queues, websockets, etc.). Sequence diagram for messages.set event with isLatest and progress propagationsequenceDiagram
participant BaileysStartupService
participant ChannelStartupService
participant EventManager
participant WebhookController
actor WebhookConsumer
BaileysStartupService->>BaileysStartupService: receive messaging_history_set(messages, isLatest, progress)
BaileysStartupService->>ChannelStartupService: sendDataWebhook(MESSAGES_SET, messagesRaw, true, undefined, {isLatest, progress})
ChannelStartupService->>ChannelStartupService: build EmitData with extra = {isLatest, progress}
ChannelStartupService->>EventManager: emit(eventData)
EventManager->>WebhookController: emit(eventData)
WebhookController->>WebhookController: build payload {
WebhookController->>WebhookController: event, instance, data, server_url, apikey, ...extra
WebhookController->>WebhookConsumer: POST messages.set payload including isLatest and progress
WebhookConsumer->>WebhookConsumer: process messages with history sync metadata
Class diagram for updated event pipeline with extra metadata supportclassDiagram
class EmitData {
+string instanceName
+string origin
+string event
+any data
+string serverUrl
+string dateTime
+string sender
+string apiKey
+boolean local
+string_array integration
+Record_string_any extra
}
class EventManager {
+emit(eventData: EmitData) Promise_void
}
class EventControllerInterface {
<<interface>>
+set(instanceName: string, data: any) Promise_any
+get(instanceName: string) Promise_any
+emit(emitData: EmitData) Promise_void
}
class EventController {
+set(instanceName: string, data: any) Promise_any
+get(instanceName: string) Promise_any
+emit(emitData: EmitData) Promise_void
}
class WebhookController {
+emit(emitData: EmitData) Promise_void
}
class RabbitmqController {
+emit(emitData: EmitData) Promise_void
}
class SqsController {
+emit(emitData: EmitData) Promise_void
}
class WebsocketController {
+emit(emitData: EmitData) Promise_void
}
class PusherController {
+emit(emitData: EmitData) Promise_void
}
class KafkaController {
+emit(emitData: EmitData) Promise_void
}
class NatsController {
+emit(emitData: EmitData) Promise_void
}
class ChannelStartupService {
+sendDataWebhook(event: Events, data: object, local: boolean, integration: string_array, extra: Record_string_any) Promise_void
}
class BaileysStartupService {
+sendDataWebhook(event: Events, data: object, local: boolean, integration: string_array, extra: Record_string_any) Promise_void
}
EventControllerInterface <|.. EventController
EventController <|-- WebhookController
EventController <|-- RabbitmqController
EventController <|-- SqsController
EventController <|-- WebsocketController
EventController <|-- PusherController
EventController <|-- KafkaController
EventController <|-- NatsController
EventManager --> WebhookController : uses
EventManager --> RabbitmqController : uses
EventManager --> SqsController : uses
EventManager --> WebsocketController : uses
EventManager --> PusherController : uses
EventManager --> KafkaController : uses
EventManager --> NatsController : uses
ChannelStartupService --> EventManager : emit events
BaileysStartupService --|> ChannelStartupService
EmitData <.. EventManager : parameter
EmitData <.. EventController : parameter
EmitData <.. WebhookController : parameter
EmitData <.. RabbitmqController : parameter
EmitData <.. SqsController : parameter
EmitData <.. WebsocketController : parameter
EmitData <.. PusherController : parameter
EmitData <.. KafkaController : parameter
EmitData <.. NatsController : parameter
note for WebhookController "In emit, builds payload with event, instance, data, and spreads extra into root"
note for KafkaController "In emit, spreads extra into Kafka message payload"
note for NatsController "In emit, spreads extra into NATS message payload"
note for RabbitmqController "In emit, spreads extra into RabbitMQ message payload"
note for SqsController "In emit, spreads extra into SQS message payload"
note for WebsocketController "In emit, spreads extra into WebSocket message payload"
note for PusherController "In emit, spreads extra into Pusher event payload"
File-Level Changes
Tips and commands Interacting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- Using a generic extra?: Record<string, any> that is spread into the root of every payload can lead to accidental key collisions with existing fields (e.g. event, instance, data); consider either namespacing (e.g. meta/context) or explicitly whitelisting allowed keys for specific events like messages.set.
- The new extra field is completely untyped and shared across all events; if you plan to use it beyond this case, consider tightening the typing (e.g. a discriminated union or per-event payload extension) so that fields like isLatest/progress are discoverable and validated at compile time.
Please address the comments from this code review:
## Overall Comments
- Using a generic `extra?: Record<string, any>` that is spread into the root of every payload can lead to accidental key collisions with existing fields (e.g. `event`, `instance`, `data`); consider either namespacing (e.g. `meta`/`context`) or explicitly whitelisting allowed keys for specific events like `messages.set`.
- The new `extra` field is completely untyped and shared across all events; if you plan to use it beyond this case, consider tightening the typing (e.g. a discriminated union or per-event payload extension) so that fields like `isLatest`/`progress` are discoverable and validated at compile time.
## Individual Comments
### Comment 1
<location> `src/api/integrations/event/kafka/kafka.controller.ts:265-268` </location>
<code_context>
sender,
apiKey,
integration,
+ extra,
}: EmitData): Promise<void> {
if (integration && !integration.includes('kafka')) {
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard object spread of optional `extra` to avoid runtime/typing issues.
`extra` is declared as optional (`extra?: Record<string, any>`), so its type is `Record<string, any> | undefined`. Spreading it directly (`...extra`) can cause TS errors (`Spread types may only be created from object types`) and may fail at runtime if `extra` is `undefined`. Please guard the spread with a fallback everywhere it’s used, for example:
```ts
const message = {
instance: instanceName,
origin,
event,
data,
server_url: serverUrl,
date_time: dateTime,
sender,
apikey: apiKey,
timestamp: Date.now(),
...(extra ?? {}),
};
```
The same guard should be applied in the other controllers (NATS, Pusher, RabbitMQ, SQS, Webhook, Websocket) for consistency.
</issue_to_address>
### Comment 2
<location> `src/api/integrations/event/webhook/webhook.controller.ts:102` </location>
<code_context>
sender,
apikey: apiKey,
timestamp: Date.now(),
+ ...extra,
};
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider whether `extra` should be allowed to override core event fields.
Spreading `extra` after the base properties means it can override core fields like `instance`, `origin`, `event`, `data`, `apikey`, etc. If that’s not intended, either:
- Spread `extra` first so core fields always win, or
- Nest it under a dedicated key (e.g. `extra`) instead of merging.
It would also be good to clarify this contract and apply the same pattern across all emitters (webhook, websocket, pusher, kafka, etc.).
Suggested implementation:
```typescript
// NOTE: `extra` is nested and not spread so it cannot override core event fields.
// This keeps `sender`, `server_url`, `apikey`, etc. stable while still allowing
// arbitrary additional payload data under the `extra` key.
sender,
server_url: serverUrl,
apikey: apiKey,
extra,
};
```
To fully implement the contract consistently across the codebase, you should also:
1. Apply the same “nest under `extra` instead of spreading” pattern in other emitters (websocket, Pusher, Kafka, etc.), replacing `...extra` with `extra` in their payload construction.
2. Update the `EmitData` (or equivalent) type/interface to document that arbitrary fields are carried in an `extra` object and that core event fields cannot be overridden.
3. Optionally add similar inline comments in other emitters to make the non-overriding behavior explicit for future maintainers.
</issue_to_address>Sourcery is free for open source - if you like our reviews please consider sharing them ✨ Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Sorry, something went wrong.
Comment thread
src/api/integrations/event/webhook/webhook.controller.ts
Outdated
- Use (extra ?? {}) to handle undefined extra safely
- Spread extra first to prevent overriding core fields like event, instance, data
- Applied fix to all 7 event controllers
Addresses Sourcery AI review feedback.
Copy link
Copy Markdown
Member
|
Please, fix the lint with npm run lint |
Sorry, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O evento messages.set não enviava as propriedades isLatest e progress do Baileys, perdendo informações importantes sobre a sincronização do histórico.
O comportamento ocorria porque o método sendDataWebhook enviava apenas o array de mensagens:
Com a sincronização de histórico do WhatsApp, é importante saber quando o sync está completo (isLatest=true) e o progresso percentual (progress).
Ajuste realizado:
ANTES:
{ "event": "messages.set", "instance": "minha-instancia", "data": [...] }DEPOIS:
{ "event": "messages.set", "instance": "minha-instancia", "isLatest": true, "progress": 85, "data": [...] }Com essa alteração, consumidores do webhook podem identificar quando a sincronização está completa e acompanhar o progresso.
📋 Description
Add support for extra fields in event payload root, specifically isLatest and progress from Baileys' messaging-history.set event.
🔗 Related Issue
N/A
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
N/A
✅ Checklist
📝 Additional Notes