How to ensure the readiness of the Azure Service Bus Emulator?

[HofmeisterAn]

Hi 👋 the Testcontainers community recently asked about an Azure Service Bus Emulator module, and it seems like many developers are looking forward to it. I decided to look into it and started working on adding the module. I set up a configuration similar to the referenced Docker Compose file, and the emulator container starts up fine without any errors 👍.

However, I ran into an issue. When I send a message to channel queue.1, I get an error.

The messaging entity 'sb://sbemulatorns.servicebus.onebox.windows-int.net/hello-queue' could not be found. To know more visit https://aka.ms/sbResourceMgrExceptions. TrackingId:256027e76d1e4df6a348e1aa9d674be9_G0, SystemTracker:gateway1, Timestamp:2024-11-23T09:21:53 (MessagingEntityNotFound). For troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.

At first, I thought my setup might be incorrect or that I needed to configure the client specifically for the local environment. But after trying all sorts of things, I realized that simply waiting a bit longer before sending the message makes the test succeed.

The module currently uses log message Emulator Service is Successfully Up! to detect and indicate readiness. The problem is that if I send the message right after the log message appears, the test fails. But if I wait just a little longer, the test works. It seems like the log message is being written before the service is actually ready to process requests.

Do you have any guidance on how to detect if the service is ready to process requests?

Steps to reproduce:

1. git clone -b feature/add-azure-service-bus-emulator [email protected]:testcontainers/testcontainers-dotnet.git
2. cd testcontainers-dotnet
3. Run the ServiceBusContainerTest test
4. Uncomment/comment the mentioned pause

[NelsonBN]

First of all, it's great to know you're already working on this, @HofmeisterAn .
I've already started running some tests to check how stable the emulator is to see if it's viable to use in my company's integration tests.

Unfortunately, I came across the same issue with the queue intermittently existing or not existing. I think the problem is more frequent when running in the pipeline. https://github.com/NelsonBN/demo-servicebus-emulator-dotnet/actions

Maybe because when running locally in debug mode or with all the test tools of Visual Studio, the process is slower, giving the queues enough time to be ready.

The best solution I've found so far is using a delay. https://github.com/NelsonBN/demo-servicebus-emulator-dotnet/blob/5a6f138882a8b1e619826d750d9ab843e402934b/tests/Demo.Tests/Config/IntegrationTestsFactory.cs#L72

I've added logs to ensure the container is ready before creating a message, but the only logs I see are:
"Creating queue: ..." and then "Emulator Service is Successfully Up!" but there's nothing confirming that the queue was actually created.

It would be really important to have either a health check endpoint or, for example, for the message "Emulator Service is Successfully Up!" to only appear when the queues and topics are actually ready to be used.

[krishankumar95]

@HofmeisterAn ; Currently there is no internal health check present in both EH and SB Emulator and the log line is supposed to signal readiness.

The log line signaling the Emulator is ready to receive requests is off by few seconds (ideally 0.5s) due to internal design of the Emulator. We are tracking this as an active bug for future release along with a health check API.

Suggestion by @NelsonBN is one way out till this issue is patched.

[jrichardsz]

The emulator is based on : Platform:CBL-Mariner/Linux,X64

Which is a Linux distribution created by Microsoft’s Linux System Group which is the same team at Microsoft which created the Linux kernel used for Windows Subsystem for Linux version 2, or WSL2.

https://jreypo.io/2021/07/09/a-look-into-cbl-mariner-microsoft-internal-linux-distribution/

Problem with this Microsoft gift are

os doesn't have a package manager

microsoft/azurelinux#3878

os doesn't have /bin/bash or /bin/sh

That why even the simple RUN doesn't work

FROM mcr.microsoft.com/azure-messaging/eventhubs-emulator:latest
RUN ls -la

workaround

Using busybox to get some useful binaries

FROM busybox:1.35.0-uclibc as busybox

FROM mcr.microsoft.com/azure-messaging/eventhubs-emulator:latest
COPY --from=busybox /bin/sh /bin/sh