Zo los je UNABLE_TO_LOCK_ROW op in Salesforce-deployments

Een record dat de deployment moet bijwerken is vergrendeld door een andere transactie die tegelijkertijd draait.

Verschijnt tijdens: DML tijdens runtime, een timingconflict in plaats van een metadata- of dataprobleem

Wat het betekent

UNABLE_TO_LOCK_ROW betekent dat Salesforce geen lock kon verkrijgen op een record omdat een andere transactie, een batchjob, een geplande flow, of een gelijktijdige Apex-test, het al aan het bijwerken was. Dit is een timingprobleem, geen metadataprobleem: de deployment of de tests ervan zijn correct, maar ze botsten met iets anders dat in de org draaide.

Het komt vooral vaak voor bij master-detail-relaties, omdat het bijwerken van een child-record een lock op de parent verkrijgt voor de herberekening van roll-up summary's, waardoor twee child-inserts die tegelijk dezelfde parent proberen bij te werken om die lock strijden.

Diagnose

Veelvoorkomende oorzaken

Deployen tijdens actief org-gebruik

Een andere gebruiker of geplande job werkt dezelfde parent-records bij terwijl de Apex-tests van de deployment draaien.

Tests werken een gedeeld singleton-record bij

Meerdere testklassen werken parallel hetzelfde org-brede configuratie- of settings-record bij.

Master-detail rollups strijden om de parent

Meerdere child-inserts triggeren tegelijk herberekeningen van roll-up summary's op hetzelfde master-record.

De oplossing

Probeer de deployment opnieuw
Rijvergrendelingen zijn tijdelijk. Het opnieuw uitvoeren van dezelfde deployment slaagt vaak zodra de concurrerende transactie is afgerond.
Deploy tijdens een periode met weinig activiteit
Plan productiedeployments buiten kantooruren of pauzeer conflicterende geplande jobs eerst.
Voorkom strijd om gedeelde records in tests
Herstructureer Apex-tests zodat ze niet allemaal hetzelfde singleton settings-record binnen dezelfde transactie bijwerken.
```
for (Account parent : [SELECT Id FROM Account WHERE Id IN :parentIds FOR UPDATE]) {
    // lock parents explicitly and predictably before child DML
}
```

In de praktijk

Hoe Serpent dit voorkomt

Serpent AI plant deployments zodanig dat bekende conflicterende jobs worden vermeden, en een vergrendelde rij verschijnt als een retry met één klik op dezelfde taak in plaats van een mislukte release. Bekijk de bibliotheek met Salesforce-deploymentfouten.

Releasedashboard met conflictmeldingen in Serpent

Preventie

Geef bulkjobs en geplande flows niet-overlappende tijdvensters

Spreid geplande batchjobs, data loads en deployments zodat ze niet tegelijk strijden om dezelfde parent-records.

Ontwerp gedeelde singleton settings-records voor lage contentie

Voorkom dat veel onafhankelijke testklassen of triggers allemaal naar één org-breed settings-record schrijven; splits configuratie waar mogelijk per concern.

Bouw automatische retry in je deploymenttooling voor deze specifieke fout

Configureer CI om UNABLE_TO_LOCK_ROW specifiek te herkennen en automatisch één of twee keer opnieuw te proberen, aangezien het een van de weinige Salesforce-fouten is waarbij een kale retry de juiste oplossing is.

Gerelateerde fouten

MIXED_DML_OPERATIONNog een fout in de transactiestructuur, deze gaat over object type-isolatie in plaats van concurrency.ALL_OR_NONE_OPERATION_ROLLED_BACKEen gerelateerd bulk-DML-faalmodus, deze komt door datageldigheid in plaats van timing.UNKNOWN_EXCEPTIONDe catch-all die Salesforce teruggeeft wanneer het een fout helemaal niet aan een specifieke regel kan toeschrijven.

Veelgestelde vragen

UNABLE_TO_LOCK_ROW, uitgelegd

Wordt UNABLE_TO_LOCK_ROW ooit veroorzaakt door slechte metadata?

Zelden. Het is bijna altijd een timingconflict met een ander proces, waardoor het simpelweg opnieuw proberen van de deployment de meeste gevallen oplost.

Voorkomt het gebruik van FOR UPDATE in SOQL deze fout, of veroorzaakt het die?

FOR UPDATE verkrijgt doelbewust een lock, dus het kan UNABLE_TO_LOCK_ROW veroorzaken als een andere transactie de lock al vasthoudt; correct gebruikt maakt het vergrendeling expliciet en voorspelbaar in plaats van onbedoeld.

Hoe vaak zou een pipeline het opnieuw moeten proberen voordat dit als een echte fout wordt behandeld?

Twee of drie retries met een korte vertraging ertussen vangt de overgrote meerderheid van tijdelijke lockconflicten; als het daarna nog steeds mislukt, behandel het dan als een echt ontwerpprobleem dat onderzoek verdient.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingesteld. Geen DevOps-aanwerving nodig.

Start gratis Boek een demo