Could not resolve row id for path!" errors when I create folders

[I’m gonna talk to myself here, as this issue comes up every once in a while, and I want to make sure it’s documented here :slight_smile: ]

A Toolkit user is getting the error “Could not resolve row id for path!” when they create folders.

Oddly, this is creating FileSystemLocation entities, but sometimes resulting in duplicates, which can cause a whole host of problems.

The full error looks something like:

Creating folders, stand by...

ERROR: Could not resolve row id for path! Please contact support! trying to 
resolve path '\\server\nas_production\CLICK\00_CG\scenes\Animation\01\001'. 
Source data set: [{'path_cache_row_id': 8711, 'path': 
'\\\\server\\NAS_Production\\CLICK\\00_CG\\scenes\\Animation\\01\\001', 
'metadata': {'type': 'shotgun_entity', 'name': 'sg_scenenum', 'filters': 
[{'path': 'sg_sequence', 'values': ['$sequence'], 'relation': 'is'}], 
'entity_type': 'Shot'}, 'primary': True, 'entity': {'type': 'Shot', 'id': 
1571, 'name': '001_01_001'}}, {'path_cache_row_id': 8712, 'path': 
'\\\\server\\NAS_Production\\CLICK\\00_CG\\scenes\\Animation\\01\\001\\Fx', 
'metadata': {'type': 'shotgun_step', 'name': 'short_name'}, 'primary': True, 
'entity': {'type': 'Step', 'id': 6, 'name': 'FX'}}, {'path_cache_row_id': 
8713, 'path': 
'\\\\server\\NAS_Production\\CLICK\\00_CG\\scenes\\Animation\\01\\001\\Comp',

(actually it can go on much longer than that…)

What does this error mean and how do I fix it?

2 Likes

What’s causing the error?

This error points to a mismatch between the storage roots as specified in Shotgun (Site Prefs -> File Management) and config/core/roots.yml in the Pipeline Configuration.

It often comes up because of a case mismatch in studios running Windows. Their paths are case-insensitive, but our configs are case-sensitive. A difference as simple as E:\Projects vs E:\projects can cause this error.

What’s happening behind the scenes?

I believe what’s happening is this: The code creates the FilesystemLocation entity in Shotgun for the path it just created, using Shotgun’s storage roots to determine the root for the path. Then, it goes to create the same entry in the local cache, and has to determine where to put it in the database. For the local cache, it uses roots.yml to determine the root for the path, and because of the case mismatch, the path it generates doesn’t match what was just entered in Shotgun. At this point, it throws the error.

It’s especially bad because it doesn’t error cleanly: the folders are created, the FilesystemLocation entries are created, they are not synced in the local path cache, nor will they ever be able to be synced because of the storage root mismatch.

How to fix

  • First, make sure the storage root paths in the Site Prefs match the paths in config/core/roots.yml . Fixing the mismatch should make the error go away in subsequent folder creation calls.
  • Clear the bad FilesystemLocation entities. If you can narrow down to a set of errant FilesystemLocation entities, just remove those. In a lot of cases though, all of the paths for a project are compromised, so they all need to go.
    • How to clear the FilesystemLocation entities: ideally you can run tank unregister_folders . To clear all of them, run tank unregister_folders --all . (For all the options for tank unregister_folders , just run it and it will output usage notes.)
    • However, because the db is already in a wonky state, this may not work, or may only partially work. Once you’ve run the command, go back to FilesystemLocations in Shotgun, and confirm that what you expected to be deleted is actually gone. If not, select the bad entities, and move them to trash manually.
  • At this point, the FilesystemLocations in Shotgun are clean, but artists’ local caches may not reflect your changes. The last step is to actually sync the local cache on each user’s machine. To do this, they should run tank synchronize_folders --full .

Once all those steps are taken, the path cache should be in a good state, and that error shouldn’t appear anymore.

Related Links

4 Likes