---
title: "Comment by Ahmet Özel on \"Deleting Personal Data from a RAG System in .NET\" | Hashnode"
description: "The distinction between an obsolete writer being cancelled and its external write actually settling is the important race here. A timed-out upsert can still com"
url: "https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f"
---

[Discussion](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943)

Comment [Deleting Personal Data from a RAG System in .NET](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 4](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f)

The distinction between an obsolete writer being cancelled and its external write actually settling is the important race here. A timed-out upsert can still complete at the provider after a verification lookup has reported absence.

I would add a test that delays the provider commit until after the first verification attempt, rather than only pausing the worker before the write. Completion evidence should identify the writer generation and settled pending-write set it was checked against. A timestamped negative lookup alone is a snapshot, not proof that no already-issued request can recreate the artefact.

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Oct 4](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f#reply-6ac296c48e7de5c668c30dfb)

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.

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 4](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f#reply-6ac29a2d7a597812ba13a4bf)

You are right: settling outstanding writes and reconciling uncertain outcomes is already required in that section. My comment should have framed the delayed commit as a concrete test of your existing invariant, rather than suggesting the invariant was missing.

I would have that test assert the request remains pending after the first negative lookup, then completes only after the delayed provider result is reconciled and verification runs again. A separate case where the provider never settles would confirm that the deadline produces an unresolved outcome rather than false completion.

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Oct 6](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f#reply-6ac53e950b369cf642d7463c)

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.

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 7](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6ac2925502c54c62417e061f#reply-6ac6558b6e54bc893ba94e28)

Those two outcomes should remain distinguishable in the completion evidence as well as the test assertions. The delayed-commit case can record the reconciled write result and the subsequent verification; the never-settles case should preserve the unresolved write identifier and generation.

A later reconciliation must then resume the pending request without treating the earlier deadline as evidence of absence. That gives the tests an observable state transition to assert, while keeping the existing settle-before-verification invariant explicit.