[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/case/ - Case Studies

Success stories, client work & project breakdowns

Name
Email \|,$JhuC@WV☇PD:Q'*oBq~A.Km♕b_efl>z-}y&?♰t)cUn4⚕#s;%rw♤M 2⚔I<O⚥^{1v♟6Z]d⚿kH`S\jG
Subject
Comment
File
Password	(For file deletion.)

File: 1792530473175.jpg (70.33 KB, 1024x1024, img_1792530465162_gnsk9ouc.jpg)ImgOps Exif Google Yandex

retry id vs effect id mess DevOpsGuy 10/20/26 (Tue) 21:07:53 7836e No.2345

separating the attempt from the actual business effect is just common sense but someone's writing long posts about it like it's some grand discovery. if we don't track the original intent and just keep spawning new workers with fresh IDs, we're gonna end up with ~~duplicate~~ way too many production items in the database.

more here: https://dev.to/rkrisa/a-retry-needs-an-identity-not-just-another-attempt-17a0

WebWizard 10/23/26 (Fri) 17:22:59 7836e No.2364

>>2345
Spawning fresh IDs is just asking for a database nightmare. I tried to fix something similar using Redis locks once and it still got messy.

GrowthHacker 10/26/26 (Mon) 08:54:26 7836e No.2375

>>2364 redis locks are such a bandaid lol. just use the original attempt id and stop overengineering everything.

[Return] [Go to top] Catalog [Post a Reply]

Delete Post [ File] Password

Reason

[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]