fix(newsletters): require the send list to resolve against the connected ESP

[jason10lee]

All Submissions:

• Have you followed the Newspack Contributing guidelines?
• Does your code follow the WordPress coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

A newsletter keeps the list it was saved with when a site switches email service providers. The new provider has never heard of that list, so the send confirmation has nothing to show, drops the "You're sending a newsletter to…" line, and leaves Send enabled anyway. The author sees a newsletter that looks ready to go and an audience that does not exist.

Send now requires the saved list to resolve against the connected provider, rather than only to be set. A newsletter with an orphaned list is blocked the same way one with no list at all already was.

The hard part is telling "this list is gone" apart from "the lists have not loaded yet". Get that wrong and Send is disabled on healthy newsletters, which is worse than the bug. The signal the check trusts is the editor's retrieve request, because every active provider asks that request for the saved list by id and widens only when the lookup fails. Once it has completed, a saved id still missing from the result did not resolve. That reasoning also survives the cap on how many lists retrieve returns for the autocomplete — ActiveCampaign returns the first ten — because the saved id is requested explicitly rather than hoped for among the first page.

The obvious alternative was the store's hasRetrievedLists flag, which reads exactly like "the lists are loaded". It was the first approach taken here, and it does not work: only the sidebar's own fetch ever sets it, so the guard stayed asleep whenever the Newsletter Campaign panel was collapsed. That is also the case where the sidebar's warning cannot render at all, so it is precisely where the author would otherwise get no signal. Unit tests passed against that version; running it against a live provider is what exposed the gap.

Two things are deliberately out of scope. The saved id is not cleared, because every provider's send path reads an explicitly unset sublist id as "send to the whole list", and writing a null to mean "could not resolve" would disarm that guard. And nothing renders the reason on screen: a disabled Send button matches how a missing list already behaves, and the missing explanation is tracked separately in NPPM-3231.

Reference: NPPM-3138

How to test the changes in this Pull Request:

Setup: a site with Newspack Newsletters and an email service provider connected.

1. Create a newsletter, set a sender and a valid send list, and save it. Send is available.
2. Point it at a list the connected provider does not have. Either connect a different provider under Newsletters → Settings, or set the meta directly: wp post meta update <id> send_list_id not-a-real-list.
3. Reload the editor. Send is now disabled.
4. Expand the Newsletter Campaign panel. The sidebar warns that the saved list is unavailable.
5. Collapse that panel and reload. Send stays disabled, which is the case the previous approach missed.
6. Choose a list the provider does have. Send becomes available again.

Same site and provider, differing only in the saved list. A valid list keeps Send available:

A list the provider does not have blocks it:

With the panel expanded, the existing sidebar warning and the blocked Send appear together:

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully run tests with your changes locally?

Verified against a live ActiveCampaign account with a Mailchimp audience id as the saved list, so the orphan is a real cross-provider one rather than a fabricated value. Both directions were checked with the Newsletter Campaign panel expanded and collapsed. The suite is 343 tests; the new cases fail against the pre-change code.

One thing this does not establish: what the provider does if a send is somehow triggered with an unresolvable list. This change removes the route to it from the editor, which is the argument for why it stops mattering, but that argument is untested.

Release risk: Low

Signal	Reading
Blast radius	Editor JavaScript in newspack-newsletters only. No PHP, no schema, no cross-plugin contract.
Failure mode	A wrong answer disables Send on a valid newsletter. The guard withholds judgement until the provider has answered, and the collapsed-panel and valid-list cases are both covered by tests.

[Copilot]

Pull request overview

Updates the Newsletters editor send guard to prevent sending when a newsletter’s saved send_list_id no longer resolves against the currently connected ESP (e.g., after switching providers), addressing a UX gap where Send could remain enabled for an orphaned audience.

Changes:

• Add getSettledSendLists to gate list-resolution checks on the ESP retrieve lifecycle instead of sidebar-only list fetches.
• Extend validateNewsletter to optionally validate that the saved list id exists in the resolved ESP lists (while avoiding false negatives during loading).
• Add unit tests covering the new “settled vs. unsettled lists” behavior and unresolved-list validation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
plugins/newspack-newsletters/src/newsletter-editor/utils.test.js	Adds focused unit coverage for settled list gating and unresolved saved list validation.
plugins/newspack-newsletters/src/newsletter-editor/utils.js	Introduces getSettledSendLists and enhances validateNewsletter to require saved list resolution once data is settled.
plugins/newspack-newsletters/src/components/send-button/index.js	Wires the send button validation to use settled ESP lists so orphaned lists disable Send reliably (even when the sidebar panel stays collapsed).

Suppressed comments (1)

plugins/newspack-newsletters/src/newsletter-editor/utils.js:73

• The sendLists JSDoc implies only null represents an unsettled fetch, but the implementation treats an empty array as “unknown” as well (it won’t report an unresolved list). Updating the doc to reflect the actual contract will prevent future callers from assuming [] is a settled/authoritative roster.

 * @param {?Object[]} sendLists         Send lists fetched from the connected ESP,
 *                                      or null when that fetch hasn't settled.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jason10lee]

We've addressed the suppressed finding in Copilot's review above by updating the docblock to reflect that null or empty means the fetch has not settled.