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
.CreateCloudTableClient()
.GetTableReference("Events");
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
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?