# renewedAt stays null when a renewal includes a scheduled plan change

**Project:** Bugs | **Board:** Closed | **Votes:** 1
**URL:** https://roadmap.vatly.com/projects/11-bugs/items/16-renewedat-stays-null-when-a-renewal-includes-a-scheduled-plan-change

---

Already fixed on our end with a workaround (deriving period start from nextRenewalAt minus one interval), so not blocking — flagging for your data model since it still looks like a real gap.

Tested via the same flow as the recent subscription.updated-on-renewal fix (confirmed working on our end, thanks). Scheduled downgrade → fast-forward-renewal {paymentStatus:"paid"}. subscription.updated now arrives correctly with the new plan — but renewedAt in that payload is null, while nextRenewalAt is correctly updated.

Note: this symptom was mentioned once before in item #10 ("Follow-up on the fast-forward-renewal issue," now Fixed), but as a side-detail of a different, unrelated bug (a failed-payment simulation producing a successful payment). This repro is a clean, separate scenario — a normal downgrade taking effect, webhook correctly delivered — so either that earlier fix didn't cover the renewedAt population itself, or this is a recurring gap across different renewal paths. Flagging in case it's useful context, not reporting a duplicate.

---

## Comments

**RAHANETRA Jason** (2026-10-03T17:45:59+00:00):
Quick follow-up with more data: it's not just null on the first transition — on subsequent renewals-with-scheduled-plan-change, renewedAt comes back non-null but stale, frozen on the timestamp of a previous unrelated order.paid (e.g. from an earlier immediate upgrade) rather than reflecting the current renewal. Reproduced this twice on two different subscriptions. nextRenewalAt stays reliable and correctly advances each time though, so we ended up deriving period-start from nextRenewalAt minus one interval instead of trusting renewedAt at all on this path — works correctly in our testing, but flagging in case renewedAt is meant to be authoritative elsewhere in your data model.

**Sander** (2026-10-14T21:02:00+00:00):
Thanks for the detailed report, Jason. We looked into this and couldn't reproduce it on the current version, so I'm closing this item.

`renewedAt` is set when a renewal payment is confirmed. `nextRenewalAt` moves forward earlier, when the renewal is created, so the two can briefly differ while a renewal payment is pending. Renewals that also apply a scheduled plan change are confirmed the same way, and we added a test to keep it that way. The stale values you saw most likely came from before the renewal confirmation changes had fully rolled out.

If you see it again, please comment here with the subscription id and we'll reopen.