AddSpatialIndex fails with ERROR 000464 after Project.Current.SaveEditsAsync() for shapefile (ArcGIS Pro SDK 3.x)

[rdc_hirohara]

Environment:
- ArcGIS Pro 3.3
- ArcGIS Pro SDK for .NET
- C# Add-in
- Target data: Shapefile (.shp)

Problem:
In an ArcGIS Pro add-in, I sometimes get the following error when trying to run management.AddSpatialIndex on a shapefile immediately after saving edits:
ERROR 000464: Cannot get exclusive schema lock.
Another application or service is editing or using this data.
(ErrorCode = 464)

This happens even though:

• The shapefile is only used inside the same ArcGIS Pro session

• All FeatureClass / Row / Cursor objects are properly disposed (using)

• No other application is accessing the shapefile

Interestingly, right after this error occurs, I can manually run Add Spatial Index
from the Geoprocessing UI on the same shapefile, and it succeeds without any problem.

Typical flow (simplified)

await Project.Current.SaveEditsAsync();

// Immediately after SaveEditsAsync
await Geoprocessing.ExecuteToolAsync(
    "management.AddSpatialIndex",
    Geoprocessing.MakeValueArray(shapefilePath)
);

Observations

• The error does not always reproduce

• It is more likely to happen:

  • Right after starting ArcGIS Pro

  • Or early in the day (first execution)

• Adding a delay (e.g. Task.Delay(200~400ms)) reduces the frequency,
  but does not completely eliminate the issue

• File Geodatabase / Enterprise Geodatabase do not show this problem
  (only shapefiles)

My understanding

It looks like Project.Current.SaveEditsAsync() returns before all internal
locks related to shapefiles are fully released, and
AddSpatialIndex requires an exclusive schema lock, which sometimes cannot
be obtained immediately after saving edits.

Questions

1. Is this a known behavior/limitation when using shapefiles with
   SaveEditsAsync() + geoprocessing tools?

2. Is there a recommended or supported way to:

   • Wait until the schema lock is fully released?

   • Or reliably detect that it is safe to run AddSpatialIndex?

3. Is using a retry / delay loop the only practical workaround?

4. Has this behavior changed or improved in newer versions of ArcGIS Pro / SDK?

Any guidance or best practices would be greatly appreciated.

[rdc_hirohara]

Additional note:
The error can occur even when all FeatureClass / Row / Cursor objects
are properly disposed using 'using' blocks.

[Aashis]

As a workaround, can you convert line #1 to Project.Current.SaveEditsAsync().Wait(), which converts asynchronous code to synchronous by blocking the main thread until the task is completed

[rdc_hirohara]

Hi Aashis,

I tried modifying the code as follows:

var saved = Project.Current.SaveEditsAsync().GetAwaiter().GetResult();
if (!saved)
{
    // throw exception
}
await CheckUtility.RebuildSpatialIndexAndRefreshLayerAsync(
    new FeatureLayer[] { logLayer }, logFile, currentWorkspace);

However, the same 464 error still occurs. 

Since rebuilding a spatial index for a shapefile (especially for a temporary / log feature class) is not always strictly required, I am planning to handle this case as follows:

• If a 464 error occurs during spatial index rebuilding for a specific feature class (e.g. a log or temporary layer),
• Treat it as non-fatal and continue processing.

This approach allows the main processing to proceed without being blocked by a schema lock on non-essential data.

Thank you very much for your suggestions.