Unexpected Subscription Version

Questions
1

Hello,

Currently I’m seeing some strange behavior I haven’t seen before and wanted to know if something changed or if something was unintentionally broken. This is specific to the sandbox environment as far as I know.

Expected:

  • When I cancel a subscription, the response version should be incremented higher than the previous version.

Actual:

  • The subscription response version is exactly the same.

Steps to reproduce:

  1. Create a new subscription within the API Explorer

    • Expected: version=1
    • Result: version=1

  2. Cancel the newly created subscription within the API Explorer

    • Expected: version=2
    • Result: version=1

Our system heavily relies on the webhooks for CQRS and our read models aren’t properly being updated due a check to see if our datastore’s current version is less than the updated version.

UPDATE Table
SET ...
WHERE ... AND Version < UPDATED_RECORD.Version

This update is currently failing due to the version not being incremented as expected. We’re wondering if this is going to be an upcoming change or if this was unintended.

Thanks for the help!

2

When a subscription is canceled its still valid till the end of the current billing cycle so it’s not updated to be canceled till the end of the current cycle. This is why there isn’t any events triggered. :slightly_smiling_face:

3

Hey Bryan,

The event fires as I would expect with the canceled_date property hydrated with the time of cancellation. Since that property updated, I would expect that the version increments as well.

Creation response

{
  "subscription": {
     ...
    "canceled_date": null /* Not actually returned, but for discussion purposes  */
    "version": 1,
}

Cancellation response

{
  "subscription": {
     ...
    "canceled_date": "2023-08-10" 
    "version": 1, /* Previously would be 2 */
}

The behavior I’m describing, the version incrementing on cancellation, is how the API previously behaved. This is a relatively recent change, within the last week or so I would say.

Update:

This isn’t applicable to just the Cancellation response, but also the actual webhook payload and subsequent queries. The write does not appear to trigger a version increment.

P.S. I’m seeing this behavior in the sandbox environment, as far as I know production is still functioning as expected.

4

Okay, I’m reaching out to the team. :slightly_smiling_face:

5

Thanks Bryan!

And to put anyone’s mind at ease - production is still functioning as expected :slight_smile:

6

Hey Bryan,

I’m circling back to this to see if there has been any update or new information available.

Thanks!

7

@Bryan-Square

I’m disappointed to say this is the behavior we’re now seeing in production a month later after voicing what we believed was a bug in the lower environment.

Are there any updates you can provide?

Edit: I’ve attached an example webhook event. Our expectation is that when the cancellation occurs, that the entity version is incremented because the entity itself has changed. This is not the behavior we’re seeing. As the example shows the entity version is still 1 even after cancellation occurs.

image
image2453×1197 154 KB