Cannot display a table if there is a property named lowercase-p "partitionKey"

[misholson]

Storage Explorer Version

1.38.0

Regression From

No response

Architecture

x64

Storage Explorer Build Number

No response

Platform

Windows

OS Version

Windows 11

Bug Description

I've found that if I have a property in my entity called partitionKey with a lowercase "p", this is allowed by Azure Tables, but Storage Explorer will display a blank tab.

This is not a big deal, I was able to remove the offending data. However, sometime between 1.24.3 and now the UI changed. In 1.24.3, you'd get a blank page of results and a spinner that ran indefinitely. You could then enter a query and as long as it didn't cross the bad entity you'd get results.

However, in 1.38.0 and a couple other versions I tried you end up with just the blank screen in the screenshot above and the whole table is basically inaccessible.

I know the first thing you're going to say is "Why would you create a property called partitionKey when you know that there's already PartitionKey and that's important?" It had to do with creating an entity that defined a job that was scanning other entities. So there was a parameter called tableName and and called partitionKey to define the entities the job would be acting on.

Anyway, once I deleted that property from the entity the table started working again.

I also discovered the following:

• rowKey with a lowercase-r also fails in the same way.
• timestamp with a lowercase-t allows you to see the search results, but the bad value shows up in the regular Timestamp column

Steps to Reproduce

• Navigate to the table in a tool OTHER than Azure Storage Explorer (I used the Storage Browser in the Azure Portal)
• Create a test table.
• Add an entity. PartitionKey and RowKey can be anything. Also add a property called "partitionKey" with a lower-case p, with any value.
• Try to open the table in Azure Storage Explorer.
• It will just display as blank and you will not be able to access the table at all.

Actual Experience

You cannot open the table. It shows as a blank tab.

Expected Experience

Ideally, you'd be able to see the entity. Naming a property "partitionKey" is surely not best practice, but it is allowed by Tables.

Failing that, an error message should display, or be logged in the Storage Explorer logs, or in the system Event Viewer, that would allow a user to troubleshoot why their table doesn't work.

Or at the very least, display the table without the offending entity so that other entities are still available to the user.

Additional Context

No response

[craxal]

@misholson It's possible some of the data used to cache column settings has been corrupted somehow.

Can you do the following:

1. Locate your app settings file.
   1. Open the Settings panel.
   2. Click the "Open settings file..." button.
   3. Use your default editor to locate the directory.
2. In the same directory as your app settings, open the config.json file.
3. Share the value of the tableExtension.tableExplorer.columnData entry.

If you delete this data and try opening your table again, does the problem persist?

[misholson]

My first thought when looking into this was that it had to do with a corrupt cache, and with that in mind I tried:

• Deleting the relevant entry from the config.json
• Deleting the entire tableExtension.tableExplorer.columnData line
• Deleting the entirety of AppData/Roaming/StorageExplorer
• Deleting AppData/Local/Programs/Microsoft/Azure Storage Explorer
• Uninstalling and reinstalling multiple versions.

The only thing that fixed it was removing the table property called partitionKey from the offending entity. Once I did that it started working again.

Here's a test case of the table as viewed through the Azure Portal's Storage Browser:

Here's that same table in Azure Storage Explorer:

Here is the value in config.json for that table:

\"https://cxdev.table.core.windows.net/AzStorageExplorerDebugging\":{\"timestamp\":1744912794876,\"state\":{\"columns\":[{\"id\":\"PartitionKey\"},{\"id\":\"RowKey\"}],\"sortByColumnId\":\"PartitionKey\",\"sortByOrder\":\"ascending\"}}}

[craxal]

@misholson Interesting. Can you share your app logs?

[misholson]

Here you go. I'd note that this should be pretty easy to reproduce. Go to the Azure Portal -> Storage Accounts -> Pick an account -> Storage Browser -> Tables -> Pick a table -> Add Entity -> Add a property called "partitionKey" with any value. Then try to open that table in Azure Storage Explorer.

2025-04-23_090829.zip

[craxal]

@misholson This appears to be a bug in the @azure/data-tables library that we use.

The library represents table entities as JavaScript objects, where each property represents an entity property. System properties are represented as strings, and custom properties are represented as objects with value and type fields. For example:

{
  "partitionKey": "p1",
  "rowKey": "r1",
  "timestamp": "2025-06-01T10:10:30.0000000Z",
  "custom": { "value": true, "type": "Boolean" }
}

The issue arises from the fact that the library uses camelCasing for system names, so PartitionKey is stored as partitionKey. This name, of course, clashes with the partitionKey custom property. The library gets confused and ends up associating the value/type object of the custom property with the system property name:

{
  "partitionKey": { "value": "OOPS! I should be the custom property 'partitionKey'", "type": "String" },
  "rowKey": "r1",
  "timestamp": "2025-06-01T10:10:30.0000000Z",
}

This breaks Storage Explorer's type expectations. So, when we try to call certain string methods, like localeCompare(), on the property value, it throws, because the value is actually an object, not a string.

I've opened Azure/azure-sdk-for-js#34687 so they know this needs to be fixed. Unfortunately, this would likely become a breaking change on their part, so I would not anticipate a quick fix.

The best workaround I can think of would involve the following:

• Continue using other tools, such as the Storage Browser in the Azure Portal.
• Modify your table data and solution to use more distinct property names to avoid case sensitivity questions. You could use a non-JS client library to walk the table and modify the necessary entities and update your solution to look for the modified property name instead.

These are not ideal, I know. But they are probably your best options at the moment.

[misholson]

That is some pretty impressive code sleuthing! Luckily this was pretty easy for me to work around. There was only one offending entity and it was easy to change the name of that property without breaking other things.

Thanks so much for looking into it!