Based on #17200; we have decided that if the local db and catalog have a conversion object with the same creative_set_id && same name but different url_pattern, update with the url_pattern from the catalog.
We do not want to write a new row bc updating the url_pattern via the catalog is often done to correct set up mistakes.

With VAC, it is crucial to update the row rather than creating a new one because we necessarily need the advertiser_public_key value, else we cannot encrypt for the conversionEnvelope

cc: @jsecretan @tmancey

Based on #17200; we have decided that if the local db and catalog have a conversion object with the same creative_set_id && same name but different url_pattern, update with the url_pattern from the catalog. We do not want to write a new row bc updating the url_pattern via the catalog is often done to correct set up mistakes.

With VAC, it is crucial to update the row rather than creating a new one because we necessarily need the advertiser_public_key value, else we cannot encrypt for the conversionEnvelope

cc: @jsecretan @tmancey

This was resolved in a previous browser release.

Most of this has been completed as part of other work. The only client-side tasks remaining are to change the primary key from creative set id to creative_set_id/name in the creative set conversion database table and to parse and add a name for each conversion which should be added to the confirmation token redemption payload for conversions. If the name node does not exist use an empty string, i.e., no-name. name will be added to a future catalog.

Based on #17200; we have decided that if the local db and catalog have a conversion object with the same creative_set_id && same name but different url_pattern, update with the url_pattern from the catalog. We do not want to write a new row bc updating the url_pattern via the catalog is often done to correct set up mistakes.

With VAC, it is crucial to update the row rather than creating a new one because we necessarily need the advertiser_public_key value, else we cannot encrypt for the conversionEnvelope

cc: @jsecretan @tmancey

Confirming this was fixed separate to this issue in the distant past.

@btlechowski this will require server-side changes, not-planned as of yet, however for QA we can override the catalog and add an optional urlPatternName for the conversion, if this optional field is not provided urlPatternName will use urlPattern as its name.

@ShivanKaul I will raise an privacy review once the PR is complete. Thanks