[Bug] v1.14.2 — back-in-stock emails no longer dispatched after latest release

[allpartsnet]

Environment: VTEX IO, vtex.availability-notify@1.14.2, workspace master
Behavior before update: When a SKU returned to stock, subscribed customers received the "BACK IN STOCK" email correctly.
Behavior after update: After the app was updated to v1.14.2 (approximately April 2026), no emails are being dispatched on stock replenishment. The subscription form still works and records are saved in Master Data V2 (entity notify). The "BACK IN STOCK" template in Message Center is active.
Manual endpoint test: Calling process-unsent-requests manually also does not trigger emails.
Question: Was there any change in v1.14.2 related to the event listener (Broadcaster) or the email dispatch pipeline that could explain this regression? The timing of the issue matches the release date exactly.

[Bug] v1.14.2 — Back-in-stock emails no longer dispatched after latest release

Summary

Since the app was updated to v1.14.2, back-in-stock notification emails are no longer being sent to customers who subscribed via the "Notify me" form. The regression appears to be directly correlated with this release — the feature was working correctly on the previous version.

---

Environment

App = vtex.availability-notify
Version = 1.14.2
Store framework = VTEX IO
Workspace = master
Account type = Seller

---

Steps to reproduce

1. Install vtex.availability-notify@1.14.2 on a VTEX IO store
2. Set a SKU to out-of-stock
3. Visit the product page and submit the "Notify me" form with a name and email
4. Confirm the record is saved in Master Data V2 (entity: notify) ✅
5. Replenish the SKU inventory (set quantity > 0)
6. Wait for the back-in-stock email to be dispatched ❌ — email is never received

---

Expected behavior

When a SKU returns to stock, all customers who subscribed via the notify form should receive the "BACK IN STOCK" transactional email, as defined in the Message Center template.

Actual behavior

No email is dispatched. The subscription records exist in Master Data V2 and the "BACK IN STOCK" template is active and correctly configured in Message Center.

---

Additional diagnostics performed

Master Data V2 — records present: Querying the notify entity confirms subscription records are being saved correctly. The front-end form is not the issue.

BACK IN STOCK template — active: The email template exists in Admin → Customer → Message Center → Templates, is enabled, and has a valid sender configured.

Broadcaster — installed: The vtex.broadcaster app is installed and active.

---

Hypothesis

The timing of the regression matches the v1.14.2 release exactly. A possible cause could be a change in:

• The Broadcaster event listener — if the app stopped subscribing to inventory change events correctly
• The email dispatch pipeline — if something in the integration with Message Center or the transactional email flow was modified
• A dependency version bump in manifest.json that introduced an incompatibility

It would be helpful to understand what changed between v1.14.1 → v1.14.2, as the CHANGELOG does not appear to be publicly visible for these patch versions.

---

Request

Could you confirm whether any change was introduced in v1.14.2 that could affect the event listener or the email dispatch flow? If so, is a patch release planned?

Thank you for maintaining this app — we appreciate the continued work on it even outside the official VTEX support scope.

[iago1501]

Hi @allpartsnet, thank you for the detailed report — this makes the investigation much easier.

About the changes in v1.14.2

We reviewed the full diff between v1.14.1 and v1.14.2. The only functional changes were:

Stricter admin user authentication on the list-requests endpoint and the listRequests GraphQL query — we added a License Manager check and an audience = admin requirement
A fix to path attributes on two outbound-access policies in manifest.json for build-time dependencies (nuget.org, bnb.data.bl.uk)
The broadcaster event listener, the email dispatch pipeline, and the Message Center integration were not modified. The code for SendEmail, ProcessNotification, and BroadcasterNotification is identical to v1.14.1.

---

What may be causing the issue

We also checked internal logs for your account (allpartsnet) and reviewed the email dispatch records for the period following the v1.14.2 release. The logs confirm that broadcaster events are arriving correctly — the app is receiving stock change notifications. However, none of those events are reaching the SendEmail stage.

It is worth noting that during the same period, SendEmail is being triggered normally for other accounts, as observed in our logs — which confirms the email dispatch pipeline itself is healthy and the issue appears to be specific to the allpartsnet account.

For process-unsent-requests to dispatch emails, three conditions must be met:

1. ListUnsentNotifyRequests returns records from Master Data with notificationSend=false
2. GetTotalAvailableForSku returns a value greater than 0 for that SKU
3. SendEmail successfully reaches the mail service

Based on what we can see in the logs, the flow is stopping before it even checks inventory — meaning the SKUs receiving broadcaster events have no matching subscribers in Master Data, or the specific SKUs with subscribers haven't had a stock replenishment event during the observed window.

---

Diagnostics we need from you

To confirm, please call the endpoint manually and share the full JSON response:

GET /_v/availability-notify/process-unsent-requests
The response looks like this:

[
  {
    "SkuId": "...",
    "Email": "...",
    "QuantityAvailable": "0",
    "Sent": false,
    "Updated": false
  }
]

• If QuantityAvailable shows "0" for SKUs you know are in stock, the issue is in the inventory check — possibly an inactive warehouse or reservations covering the full available quantity
• If QuantityAvailable is > 0 but Sent: false, the issue is in the dispatch itself — check your VTEX IO logs (Debug level) for SendEmail workflow entries showing the mail service response status

Given the complexity of the diagnosis and the fact that it may involve account-level data, logs, and inventory configuration, we recommend opening a support ticket with our team via Zendesk. This will allow us to investigate your account's logs and settings directly, which goes beyond what we can do through a public GitHub issue.

---

Additional note

We also identified a recurring VBase throttling pattern (TooManyRequests / ThrottleByCaller) in your account's logs, concentrated during business hours. This is caused by the volume of per-SKU lock calls generated during bulk stock updates. While this does not directly block email sending, it is worth noting as a signal that large inventory batch updates may be generating broadcaster events at a higher volume than expected.

We look forward to the process-unsent-requests output to move the diagnosis forward.