🐛 Fixed flaky target delivery window batch-sending test#28937
Conversation
The test asserted every batch carried an o:deliverytime, but the first/ immediate batch's delivery time is "now" at calculation time, which the sender drops once the clock ticks past it (it never schedules delivery in the past). When a millisecond elapsed between calculation and dispatch the first batch sent with no deliverytime, failing the assertion intermittently (more often on the slower mysql8 CI leg). Assert the windowed batches each carry a valid deliverytime within the deadline instead of requiring one on every batch.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe target delivery window test now collects all 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx run ghost:test:ci:integration |
✅ Succeeded | 2m 35s | View ↗ |
nx run ghost:test:integration |
✅ Succeeded | 2m 41s | View ↗ |
nx run ghost:test:legacy |
✅ Succeeded | 2m 48s | View ↗ |
nx run ghost:test:e2e |
✅ Succeeded | 2m 27s | View ↗ |
nx run-many -t test:unit -p ghost |
✅ Succeeded | 30s | View ↗ |
nx run-many -t lint -p ghost |
✅ Succeeded | 33s | View ↗ |
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗
☁️ Nx Cloud last updated this comment at 2026-06-26 19:11:02 UTC

The
Target Delivery Window > can send an email with a target delivery window setintegration test asserts that every batch is sent with ano:deliverytimeoption. This fails intermittently (seen on the mysql8 acceptance leg) withExpected: "string" / Received: "undefined".The first/immediate batch's delivery time is computed as "now" (
delay 0). The sender intentionally drops any delivery time that is no longer in the future (deliveryTime >= Date.now()inbatch-sending-service.js) — it never schedules a delivery in the past — so once a millisecond elapses between calculation and dispatch, the first batch correctly sends with no delivery time. The test then fails. On a same-millisecond run all four batches keep their time and it passes, which is why it's flaky, and more so under the slower/jittery mysql8 leg.This asserts the windowed batches each carry a valid
o:deliverytimewithin the deadline (and tolerates the immediate batch having none, without assuming worker/batch ordering), rather than requiring a delivery time on every batch.Verified locally on sqlite: passes across repeated runs.