We retried a failed Hub job. Got two assets. Same title. Different IDs. Guess which one the page used.
Retries cloned the asset
Timeout. Recipe retried. Create ran twice. I found it because the listing showed two thumbnails that looked identical. They weren't. Guess which one the page used. The worse one. That's the rule.
Retries are good. Soft keys are not. Display name is a soft key. Stable ID. Upsert. Then retry. If you can't upsert, don't retry blindly. Dead-letter it. I like retries. I like unique items more.
The clone in slow motion
First create almost finished. Network said no. Recipe didn't know. Recipe created again. Now two IDs. Authors picked from a picker that shows titles. Titles matched. They picked twice in two days. The page stacked them. Looked like a ghost. Was just math.
Cleanup is worse than prevention. Cleanup means redirects, broken links, and a DAM argument. Prevention means an ID. Do the ID.
Field ownership, yes again
If XM writes description and Hub writes description, retries look like flapping. It's two cooks. Write the map. Tape it. I will keep saying tape. Tape is cheaper than a war room.
When a field flaps, don't add a delay. Delays plus two cooks is a slower fight. Pick a cook. Unplug the other.
- External ID from Hub.
- Upsert on that ID.
- Replay twice in lower env.
- Count items after replay.
Lower environment is not optional
Replay twice. Count items. If count goes up, your key is wrong. Don't 'just ship' that recipe. Shipping a cloner is how Friday becomes a DAM weekend. I've had that weekend. The pizza was not worth it.
If you don't have a lower env that mirrors Hub, you don't have a recipe you can trust. You have a prayer. Prayers aren't idempotent.
What Connect is for
Moving known fields with known owners. Not inventing a second CMS. If you need a second CMS, say so and budget it. Don't sneak one in through retries.
I sneaked. I called it integration. Integration is a compliment. Clone is the honest word. Use the honest word in the ticket so someone stops you.
Checklist
Replay twice. Count. Confirm no clone. Confirm no flap. Confirm upsert. Confirm the ID is not a title. Confirm the picker shows IDs to someone technical at least. Authors can keep seeing titles. You need the ID when it breaks.
Monday
Turn off blind create-on-retry for one recipe. Watch dead-letter. If dead-letter stays empty and clones stop, you were retrying a cloner. Leave it off. If dead-letter fills, fix the timeout or the payload. Don't turn create back on to 'clear the queue.' Clearing the queue is how twins happen.
If You Only Do One Thing
Add a client key to the Hub recipe and log it. Run a replay on purpose. If two rows appear, you don't have idempotency. You have hope. Hope is not a key.
I watched a replay duplicate a promo module. I still see that module when I close my eyes. That's not poetry. That's a scar.
What I Won't Do
I won't add a second Hub recipe until the first one survives a replay without a new row. Second recipes are how Tuesday happened.
The Promo Module I Still See
Duplicate. Same campaign, two IDs. The homepage looked drunk. Marketing thought it was A/B. It was a replay without a key. I turned the job off with my hand shaking. Not heroic. Caffeine and shame.
Client key went in that afternoon. Logged. Ugly log. I like ugly logs. Pretty logs hide duplicates.
Hope Is Not A Key
I said that in a meeting and someone laughed. Then they stopped laughing when I showed the two rows. Hope is funny until it's a homepage.
We ran a replay after the key. One row. I still ran a second replay the next morning because I don't trust mornings after incidents. Second replay still one row. I wrote 'still one' on the ticket. That's the novel.
Second Recipe
They wanted a 'just in case' recipe for a different Hub project. I said after this one survives a week of replays. A week is arbitrary. Arbitrary is better than Tuesday. Tuesday already happened.
If you need a number, count duplicate rows per week. If it isn't zero, you don't have idempotency. You have a schedule.
Actionable checklist
- Define unique identifiers for content items.
- Create a field mapping document for ownership clarity.
- Implement hashing techniques for data verification.
- Set appropriate retry windows based on performance monitoring.
- Regularly review and adjust field ownership as needed.
- Document all sync processes and best practices.
- Test synchronization scenarios in a staging environment.
- Monitor sync performance metrics continuously.
- Train the team on idempotency and conflict resolution strategies.
- Establish a feedback loop for ongoing process improvement.