Azurite: *PANIC* when looking for non-existent row

There seems to be an inconsistency in how this emulator handles non-existent rows compared to how “real” Azure Table Storage handles them. I discovered this while using Streamstone, which builds event streaming capabilities on top of Azure Table Storage, and while I haven’t been able to discern exactly what operations they’re doing on the table storage, I have been able to build a minimal example that reproduces the problem.

To reproduce, make sure you have the dotnet CLI installed, and run

mkdir repro && cd repro
dotnet new console
dotnet add package Streamstone

Then replace the contents of Program.cs with this:

using System;
using System.Threading.Tasks;
using Microsoft.WindowsAzure.Storage;
using Streamstone;

namespace AzuritePanicOnStreamstoneTryOpenStream
    class Program
        public static async Task Main(string[] args)
            // Replace with CloudStorageAccount.Parse("your connection string"); for using a real Azure Storage Account
            var account = CloudStorageAccount.DevelopmentStorageAccount;

            var table = account
            await table.CreateIfNotExistsAsync();

            var partition = new Partition(table, "foo");

            await Stream.TryOpenAsync(partition);

Finally, run dotnet run to see the program fail with

Unhandled Exception: Microsoft.WindowsAzure.Storage.StorageException: Unexpected response code, Expected:OK or NotFound, Received:InternalServerError
   at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteAsyncInternal[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token) in C:\Program Files (x86)\Jenkins\workspace\release_dotnet_master\Lib\WindowsRuntime\Core\Executor\Executor.cs:line 315
   at Streamstone.Stream.OpenStreamOperation.ExecuteAsync()
   at AzuritePanicOnStreamstoneTryOpenStream.Program.Main(String[] args) in C:\Work\OSS\Throwaway repros\AzuritePanicOnStreamstoneTryOpenStream\Program.cs:line 17
   at AzuritePanicOnStreamstoneTryOpenStream.Program.<Main>(String[] args)

If I look at the logs for my docker container running Azurite, I see

GET /devstoreaccount1/Events(PartitionKey='foo',RowKey='SS-HEAD') 500 0.388 ms - 27
**PANIC** Something unexpected happened! Table Storage Emulator may be in an inconsistent state!
ReferenceError: partitionKey is not defined
    at TableStorageManager.queryEntities (/opt/azurite/lib/core/table/TableStorageManager.js:104:40)
    at QueryEntities.process (/opt/azurite/lib/actions/table/QueryEntities.js:12:29)
    at Object.actions.(anonymous function) [as QueryEntity] (/opt/azurite/lib/middleware/table/actions.js:52:19)
    at BbPromise.try (/opt/azurite/lib/middleware/table/actions.js:18:38)
    at tryCatcher (/opt/azurite/node_modules/bluebird/js/release/util.js:16:23)
    at Function.Promise.attempt.Promise.try (/opt/azurite/node_modules/bluebird/js/release/method.js:39:29)
    at module.exports (/opt/azurite/lib/middleware/table/actions.js:17:18)
    at Layer.handle [as handle_request] (/opt/azurite/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/opt/azurite/node_modules/express/lib/router/index.js:317:13)
    at /opt/azurite/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/opt/azurite/node_modules/express/lib/router/index.js:335:12)
    at next (/opt/azurite/node_modules/express/lib/router/index.js:275:10)
    at BbPromise.try (/opt/azurite/lib/middleware/table/validation.js:32:9)
    at tryCatcher (/opt/azurite/node_modules/bluebird/js/release/util.js:16:23)
    at Function.Promise.attempt.Promise.try (/opt/azurite/node_modules/bluebird/js/release/method.js:39:29)
    at module.exports (/opt/azurite/lib/middleware/table/validation.js:18:18)

However, if I connect to a real Azure Storage Account instead of the emulator, the program runs without error.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 6
  • Comments: 24

Most upvoted comments

Just hit this too in docker

The changes have been merged into our Dev branch to address this. We’ll merge into Master and release a new update soon. 😃

Looking closer at this, it seems like #17 might be a fix for the same problem. Is there a timeframe for when that might merge and result in a new docker image?

Is there any workaround for this? I’m currently blocked from moving to Azurite.

I hope to have an update here in the next couple of days.
We just need to iron out a few things this end.
Many thanks for your patience!

Thanks for reporting this… I’m looking into it…

@edwin-huber I just tried switching to Azurite and immediately ran into this issue. Any idea when the next update will be?