azure-functions-durable-extension: Orchestrator stops using Azurite emulator on Mac
When use the Azurite storage emulator on Mac, the orchestrator stops in the start state. It does not occur using real Azure storage. I guess it is a specific problem with using Azurite. runtime log is as follows.
[2018/05/17 5:19:49] Job host started
[2018/05/17 5:20:41] Executing 'Functions.QueueStart' (Reason='New queue message detected on 'durable-function-trigger'.', Id=e9d96802-e821-4698-87c8-62d5cb0b65ae)
[2018/05/17 5:20:41] 7b519ac2-f3bc-4ded-ab18-94b99fb4227d: Function 'E1_HelloSequence (Orchestrator)' scheduled. Reason: NewInstance. IsReplay: False. State: Scheduled. HubName: DurableFunctionsHub. AppName: . SlotName: . ExtensionVersion: 1.4.1.0. SequenceNumber: 0.
[2018/05/17 5:20:41] Executed 'Functions.QueueStart' (Succeeded, Id=e9d96802-e821-4698-87c8-62d5cb0b65ae)
my execution environment is as follows.
- MacOS: 10.13.4
- node.js: 8.11.1
- Azure Functions Core Tools: 220.0.0-beta.0
- azure-functions-durable-extension: 1.4.1
- azure-functions-durable-js: 0.03
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 5
- Comments: 15 (6 by maintainers)
Commits related to this issue
- Partial fix for https://github.com/Azure/azure-functions-durable-extension/issues/312: Change format of blob lease IDs — committed to Azure/durabletask by cgillum 6 years ago
There is now preview support for Tables in Azurite https://github.com/Azure/Azurite/releases/tag/v3.12.0.
@cgillum That seems like a legit change for now, but I think perhaps a better fix is for the Azurite project to conform to the documented spec (which might also be a one-liner over there). Anyway, there are other issues trying to get it running on a mac… I went ahead and wrote down some additional information I discovered today in Azure/Azurite#37.
Good news - the Azurite team has decided to support Tables in V3 and are specifically working to ensure compatibility with Durable Functions. You can track the status of this ongoing work here: https://github.com/Azure/Azurite/issues/253#issuecomment-664213525
Anything new?
@kylepope Oh, that’s interesting. I noticed that we actually have some control over the format of the leases. See the code here. We could make a simple fix on our side to potentially resolve that.
I don’t know what the 501 failure refers to. Do let us know if you can track that down further - hopefully it’s another issue that we can fix on our side to improve compatibility.
I’ve been struggling to get this running locally on a mac and was failing with the same error as others described here (i.e. k-miyake’s 400 error and any message in the queue being stuck as “Pending” after starting an orchestration).
That said, the 400 error may be a red herring – I tracked that down to a validation bug where Azurite is expecting a “x-ms-proposed-lease-id” HTTP header to be a UUID v3/4/5 (see lib/validation/blob/LeaseId.js). It turns out the lease IDs are not correctly formed UUIDs. Instead they are guids that are 32 characters in length (i.e. without dashes). Removing that validation code resolved some of the 400 errors I was seeing, but I’m now seeing different errors including a 501 error indicating “Cannot read property ‘tableName’ of undefined” on a POST request to “/devstoreaccount1/$batch”.
I now suspect there are some other incompatibilities here I don’t have the free cycles to figure it out at the moment. I’ll post over in the Azurite repo with some extra details next week to let them know and so others might be able to pick up where I left off… At this point I think this is probably an Azurite issue…