Un write reușit în Microsoft Entra nu garantează că următorul read vede schimbarea. Dacă ai automatizări Microsoft Graph app-only care fac Create apoi imediat Read, Assign sau Validate, acesta este genul de schimbare care îți rupe discret runbook-urile, în timp ce platforma pare în continuare "healthy".
Microsoft spune acum foarte clar cum funcționează designul: Entra este eventual consistent, mai ales pentru application-only access. Write-urile sunt acceptate mai întâi și replicate asincron între replici. În acea fereastră, un obiect nou creat poate întoarce 404 Not Found, iar o proprietate actualizată recent poate să nu apară încă la read. Asta nu este outage. Așa funcționează platforma, by design.
Pentru ingineri, partea importantă nu este teoria. Este consecința operațională: dacă automatizarea ta presupune implicit read-after-write consistency, scriptul este fragil chiar acum. Asta apare des în background jobs, provisioning flows și automatizări de tenant construite cu Graph, PowerShell, Azure Functions sau Logic Apps. Dacă îți sună cunoscut, exact acest tip de workflow l-aș verifica într-un audit AI și automation înainte să cedeze la scară.
Ce se strică de fapt
Modelul de failure este previzibil:
| Pattern | De ce cedează cu eventual consistency | Abordare mai bună |
|---|---|---|
| Create apoi GET pentru confirmare | Read-ul poate ajunge la o replică neactualizată | Ai încredere în răspunsul create și păstrează ID-urile returnate |
| PATCH apoi GET pentru verificare | Proprietatea actualizată poate fi stale | Tratează write-ul reușit ca sursă autoritativă |
| Create apoi imediat role assignment sau membership | Read-ul sau lookup-ul dependent poate întoarce 404 | Reîncearcă pasul dependent cu backoff |
| Start-Sleep fix înainte de retry | Întârzierea este arbitrară și des greșită | Folosește exponential backoff și retry-uri idempotente |
Microsoft documentează separat și problema 404-after-create în scenarii de administrare prin Graph și spune explicit că replicarea poate dura câteva minute. Soluția recomandată și acolo este tot retry, cu timp de așteptare dublat când este nevoie.
Părerea mea: pentru Microsoft aceasta este alegerea corectă de distributed systems, dar pentru clienți este o surpriză urâtă dacă și-au construit automatizările pe comportamentul observat până acum. Sunt două lucruri diferite. La scara Entra, eventual consistency are sens. Dar dacă ani de zile ai învățat din scripturi că "POST apoi GET merge de obicei", s-ar putea ca tot tenantul tău să depindă de un detaliu de implementare care nu a fost niciodată garantat contractual.
Ce trebuie să schimbi în scripturi
Regula mare este simplă: nu mai face read doar ca să te liniștești.
În practică, eu aș schimba patru lucruri:
- Ai încredere în răspunsurile de write reușite și salvează object ID-ul sau proprietățile returnate.
- Elimină GET-right-after-POST sau PATCH când sunt folosite doar pentru confirmare.
- Înlocuiește delay-urile fixe cu retry logic și exponential backoff.
- Fă fiecare pas idempotent, astfel încât retry-urile să nu creeze duplicate sau efecte secundare nedorite.
Unde read-ul este inevitabil, folosește pattern-urile Graph gândite pentru eventual consistency. Microsoft Graph documentează header-ul ConsistencyLevel: eventual pentru advanced query scenarios pe directory objects, inclusiv exemple PowerShell, cum ar fi:
Get-MgUser -Filter "accountEnabled ne true" -CountVariable CountVar -ConsistencyLevel eventual
Acest header nu rezolvă magic întârzierea de replicare, dar arată clar cum se așteaptă Graph să gândești reads pe director: nu ca tranzacții cu consistență puternică.
Iată pattern-ul PowerShell pe care l-aș folosi în runbook-uri în loc de Start-Sleep:
function Invoke-WithRetry {
param(
[Parameter(Mandatory)]
[scriptblock]$Operation,
[int]$MaxAttempts = 6,
[int]$InitialDelaySeconds = 2
)
$attempt = 0
$delay = $InitialDelaySeconds
while ($attempt -lt $MaxAttempts) {
try {
return & $Operation
}
catch {
$attempt++
if ($attempt -ge $MaxAttempts) { throw }
Start-Sleep -Seconds $delay
$delay = $delay * 2
}
}
}
$app = New-MgApplication -DisplayName "demo-eventual-consistency-app"
$appId = $app.Id
Invoke-WithRetry -Operation {
Get-MgApplication -ApplicationId $appId -ErrorAction Stop
}
Ce schimbă asta în practică
Majoritatea organizațiilor nu vor observa nimic în munca interactivă de admin. Automatizările vor observa. Zona de risc este cea a workflow-urilor conduse de service principals: provisioning, access assignment, pipeline-uri de app registration, identity governance jobs și orice lanțuiește crearea de obiecte Entra cu pași downstream.
Efectul de ordinul doi este de guvernanță: automatizările de identitate fragile, fără retry, tind să pice la jumătatea execuției, lăsând aplicații orphaned, membership parțial sau role assignments lipsă. Asta nu este doar o bătaie de cap pentru ingineri; devine o problemă de securitate și accountability. Niciun agent sau runbook nu ar trebui să primească un cec în alb ca să reîncerce la nesfârșit, motiv pentru care aș combina aceste remedieri cu o revizuire de least privilege și limite mai stricte pentru Copilot și AI agents sau custom MCP servers atunci când sunt implicate acțiuni de identitate.
Concluzia: dacă automatizarea ta Entra face read imediat după write, pornește de la ideea că este greșită și refactorizeaz-o acum. Ai încredere în răspunsul write, tratează 404-urile tranzitorii cu retry și nu mai folosi sleep pe post de control plane.
