--- title: "Patrick Kearns (@fullstackcity) | Hashnode" description: "Senior .Net Engineer. Read the latest articles by Patrick Kearns on Hashnode." url: "https://hashnode.com/@fullstackcity" --- @fullstackcity # Patrick Kearns @fullstackcity · Dublin · Joined March 2025 Senior .Net Engineer ## Comments [If you use Grapheme dont forget that counting depends on runtime versions. Modern .NETs StringInfo handles extended grapheme clusters, but versions before .NET 5 behaved differently. Browser and server Unicode versions can also differ, so test shared examples especially emoji sequences and keep server validation authoritative](https://hashnode.com/posts/unicode-bugs-that-look-like-business-logic-bugs/6acf2f9f68f66d4924d1fdb3/comment/6ad181afeec3044d0b277392#reply-6ad270c68ac87fa77d40739e) Reply · Article · Oct 16 · [Unicode Bugs That Look Like Business Logic Bugs](https://hashnode.com/posts/unicode-bugs-that-look-like-business-logic-bugs/6acf2f9f68f66d4924d1fdb3) [Yeah, f the downstream operation needs protection against stale owners, Id carry the report ID and generation through and have the receiver enforce the check atomically with its own state change. The database fence only protects the database write, it wont automatically protect a later queue message or API call.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6acfaf6b0fc54e188ed42cf9#reply-6ad07f7eb7972db3e87ff0ba) Reply · Article · Oct 15 · [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56) [Id prob combine an outbox with provider side idempotency. The fenced database transaction records the accepted result and its outbound intent together, so a superseded worker cant enqueue new work. The dispatcher then retries that intent using a stable idempotency key for the logical operation. An outbox doesnt guarantee "only the current owner ever sends". An intent accepted before ownership changed can still be delivered afterwards, and a dispatcher can itself pause with a request in flight. If that previously accepted action must now be rejected as obsolete, the destination needs a version or conditional operation check too. Idempotency alone wont establish that. Where the provider offers no check, you have to decide whether accepted intents remain valid or whether the workflow needs cancellation, reconciliation or compensation.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6ad07e155ba71273f3ad89e6#reply-6ad07f16e8a7ddf6b9bdc6f8) Reply · Article · Oct 15 · [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56) [No, the sample currently logs a generic publication refusal with the report ID and generation, it doesnt track causes separately. A structured result would be a useful extension, provided it preserves the distinction between a reason and a later diagnostic observation. The thing to remember with a downstream receiver is an idempotency key prevents duplicate execution of the same operation, but doesnt necessarily reject a distinct operation from a stale owner. The receiver needs to enforce the generation check atomically with the protected change. Otherwise it wont provide that same prevention guarantee.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6aced9ba79a9aae105350829#reply-6ad07c9351210ccf0ec3459a) Reply · Article · Oct 15 · [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56) [You could do, there are a couple of subtleties, though. An unchanged generation can also mean that generation already published or ownership was released, so it doesnt establish expiry by itself. A follow up read can help diagnose the refusal, but another acquisition could happen between the UPDATE and that read. If the adapter promises an exact reason, Id determine and return it within a short transaction that holds the row lock across the check and conditional update. Otherwise, Id treat the read as diagnostic evidence and allow an unknown outcome rather than log a definitive cause.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6aced9ba79a9aae105350829#reply-6acf274c9812fd909467949c) Reply · Article · Oct 14 · [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56) [The post deliberately applies the stricter rule that publication requires an unexpired lease, but your 31-second example highlights the cost of that choice, especially without renewal. For this report example, allowing publication until the acquisition is superseded is a better fit. Id remove that predicate and update the explanation and expiry test accordingly, keeping any source freshness requirement separate.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6ace13d7a868b35039393eb6#reply-6acf26b61175aa9e8a360b36) Reply · Article · Oct 14 · [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56) [Yeah thats it, both are useful test cases. The delayed commit case should prove that the first negative lookup cant complete the deletion while a write remains outstanding. The 'never settles' case should prove that reaching the deadline leaves the outcome unresolved.](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f#reply-6ac53e950b369cf642d7463c) Reply · Article · Oct 6 · [Deleting Personal Data from a RAG System in .NET](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943) [Yeah, thats worth measuring alongside precision and recall. Id test completeness against the evidence actually sent to the model, because retrieving a required definition or exception doesn't help if packing drops it. Questions with known evidence dependencies would make a useful comparison between top-k retrieval, parent expansion and long context, checking whether each approach preserves enough evidence to support the answer.](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac38c67c6334ea27e3bd211#reply-6ac53d7a9ca5553710ebb889) Reply · Article · Oct 6 · [RAG vs Long Context in .NET](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50) [Yeah, people often forget about the Cache!](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac0d79cade4fd09074f671b#reply-6ac296ea1e2f238c6fb4006d) Reply · Article · Oct 4 · [Deleting Personal Data from a RAG System in .NET](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943) [Yeah, that’s why the controlled writer section requires outstanding provider writes to settle before verification completes, with uncertain outcomes reconciled. The delayed commit test is a useful concrete addition to that coverage, as is tying completion evidence to the writer generation and settled write set.](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f#reply-6ac296c48e7de5c668c30dfb) Reply · Article · Oct 4 · [Deleting Personal Data from a RAG System in .NET](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943)