inferedthe payload for localization events does not contain the teant_uuid. the tenant can usually be inferred from the header, but in the case of dird, dispatch() is only passing the payload, leading to a complete loss of the tenant info.
GIVEN a Localization event is received WHEN I’m looking at the payload THEN both the country and tenant_uuid fields are present
Notes There’s two approaches that have been highlighted for this:
Adding the tenant_uuid directly in the event LocalizationDict. Pro: Quick and straightforward Cons: Duplication of data (tenant_uuid both in payload and headers) Note: There’s already quite a lot of events that have duplicated data between the headers and payload with the idea that if it’s functional data, it should be in the payload. So, arguably, one more might not be that bad ( also considering it won’t be called that often)
Overriding the dispatch() function for dird. Pro: We’re not duplicating data, just adding the headers back in the payload just before loosing access to said headers. Cons: The payload received isn’t matching the declared one. Code magic is happening, which add complexity
Zendesk Ticket IDs
None
Activity
Show:
François Blackburn March 12, 2025 at 11:50 AM
Is not the first time I see we need metadata from a message, we should consider to add a mechanism to pass raw data to the subscribed method
We can achieve it with a decorator to avoid to break all subscribed method
inferedthe payload for localization events does not contain the
teant_uuid. the tenant can usually be inferred from the header, but in the case ofdird,dispatch()is only passing the payload, leading to a complete loss of the tenant info.GIVEN a Localization event is received
WHEN I’m looking at the payload
THEN both the
countryandtenant_uuidfields are presentNotes
There’s two approaches that have been highlighted for this:
Adding the
tenant_uuiddirectly in the eventLocalizationDict.Pro: Quick and straightforward
Cons: Duplication of data (
tenant_uuidboth in payload and headers)Note: There’s already quite a lot of events that have duplicated data between the headers and payload with the idea that if it’s functional data, it should be in the payload. So, arguably, one more might not be that bad ( also considering it won’t be called that often)
Overriding the
dispatch()function fordird.Pro: We’re not duplicating data, just adding the headers back in the payload just before loosing access to said headers.
Cons: The payload received isn’t matching the declared one. Code magic is happening, which add complexity