Skip to content

feat: server-push mex notification dispatch (reachout timelock + message capping)#2445

Open
jlucaso1 wants to merge 1 commit intomasterfrom
feat/mex-notification-dispatch
Open

feat: server-push mex notification dispatch (reachout timelock + message capping)#2445
jlucaso1 wants to merge 1 commit intomasterfrom
feat/mex-notification-dispatch

Conversation

@jlucaso1
Copy link
Copy Markdown
Collaborator

Context

Follow-up to #2442 and the investigation in #2441.

The current handleMexNewsletterNotification only handles newsletter operations and assumes all mex notifications use a { operation, updates } JSON structure. In reality, WA Web routes 27+ operation types through a dispatcher that reads <update op_name="..."> from the binary node and parses a standard GQL response body ({ data, errors }). This means non-newsletter mex notifications (reachout timelock, message capping, LID changes, etc.) are silently dropped today.

What this PR does

Refactors the mex notification handler into a proper op_name-based dispatcher matching WA Web's WAWebHandleMexNotification.js, and adds two new handlers:

  • Reachout timelock (NotificationUserReachoutTimelockUpdate) — server-pushed account restriction updates, emitted via connection.update with reachoutTimeLock. Handles both restriction set (with * 1000 timestamp conversion + 60s default) and restriction lifted, matching WAWebMexReachoutTimelockNotificationHandler.js.

  • Message capping (MessageCappingInfoNotification) — server-pushed sending quota changes for business accounts, emitted via a new message-capping.update event. Matches WAWebNewChatMessageCappingNotificationHandler.js.

Existing newsletter notifications keep working via a legacy fallback path — no breaking changes.

Usage

// Reachout timelock (account restriction changes)
sock.ev.on('connection.update', ({ reachoutTimeLock }) => {
    if (reachoutTimeLock?.isActive) {
        console.log(`Account restricted until ${reachoutTimeLock.timeEnforcementEnds}`)
        console.log(`Reason: ${reachoutTimeLock.enforcementType}`)
    } else if (reachoutTimeLock) {
        console.log('Restriction lifted')
    }
})

// Message capping (business account sending limits)
sock.ev.on('message-capping.update', (info) => {
    console.log(`Quota: ${info.used_quota}/${info.total_quota}, status: ${info.capping_status}`)
})

Files changed

  • src/Socket/messages-recv.ts — new dispatcher + handlers, legacy newsletter fallback
  • src/Types/State.tsReachoutTimelockState, enforcement type enum, capping types
  • src/Types/Events.tsmessage-capping.update event

@whiskeysockets-bot
Copy link
Copy Markdown
Contributor

whiskeysockets-bot commented Mar 25, 2026

Thanks for opening this pull request and contributing to the project!

The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch.

In the meantime, anyone in the community is encouraged to test this pull request and provide feedback.

✅ How to confirm it works

If you’ve tested this PR, please comment below with:

Tested and working ✅

This helps us speed up the review and merge process.

📦 To test this PR locally:

# NPM
npm install @whiskeysockets/baileys@WhiskeySockets/Baileys#feat/mex-notification-dispatch

# Yarn (v2+)
yarn add @whiskeysockets/baileys@WhiskeySockets/Baileys#feat/mex-notification-dispatch

# PNPM
pnpm add @whiskeysockets/baileys@WhiskeySockets/Baileys#feat/mex-notification-dispatch

If you encounter any issues or have feedback, feel free to comment as well.

@jlucaso1 jlucaso1 force-pushed the feat/mex-notification-dispatch branch from 7884e72 to 36dc13a Compare March 25, 2026 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog

Development

Successfully merging this pull request may close these issues.

2 participants