#dfenerski

1 messages · Page 1 of 1 (latest)

opaque sparrowBOT
slow timber
#

👋 Hi there, Happy to help!
the event customer.subscription.updated occurs whenever a subscription changes, including the Subscription metadata updates, so you can't by pass this

grave sparrow
#

Thanks @slow timber !
Is there any other object that with the lifespan of the subscription, whose metadata I can use to attach runtime metadata info?

#

Or, if not, is there a 'reason' field in the changed event that can help me decide whether the event is 'real' ?

slow timber
tardy shuttle
#

Hey, taking over here. Let me know if there's any follow-up Qs I can answer!

grave sparrow
#

Hi @tardy shuttle , seems like I have 2 options - to use the invoice's metadata, or, more conveniently, check the reason for the event

#

Seems like I can use event.data.previous_attributes to check what got changed

#

If 'metadata' got changed - then I can ignore this event.

#

Is this approach reliable? What do you think

tardy shuttle
#

What are you trying to account for?

#

Can you summarise the issue?

grave sparrow
#

Yes: Changing subscription's metadata inside customer.subscription.changed handler triggers another customer.subscription.changed

#

After update, I want to enrich the subscription's metadata. But doing this triggers the event again. So I can either store the data elsewhere (invoice's metadata), or somehow distinguish between events

#

I also asked about whether there is a way to suppress the trigger but there seems to be none.