azure-cosmos-db-emulator-docker
azure-cosmos-db-emulator-docker copied to clipboard
Latest release takes extremely long time to start
Describe the bug I've seen major refactor etc in release. My e2e tests pulled the newest image and immediately started timing out (using test containers). Previous release was starting in 10-15s max. This release can take >2minutes to start (until gateway emits "listening").
It sounds like great progress ahead, but this is painful :(
To Reproduce Steps to reproduce the behavior:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- See error
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: [e.g. iOS]
- Browser [e.g. chrome, safari]
- Version [e.g. 22]
- SDK version
- SDK language
Additional context Add any other context about the problem here.
In the latest release, the gateway emits "listening" every 100 seconds after startup to confirm its status. However, the gateway is usually ready to accept connections 10-15 seconds after the emulator starts up. You can track this startup by probing the health server (port 8080). It will give an output like so:
This confirms that the gateway is up and running and ready to accept calls, and you can also check the health server to see if any component has gone down.
We began to see our pipelines failing yesterday afternoon. Today we were able to resolve the issue using this image mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-EN20251022 instead of vnext-preview. Running locally does not seem to be an issue, but running on the Azure DevOps build agents is timing out.
We began to see our pipelines failing yesterday afternoon. Today we were able to resolve the issue using this image
mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-EN20251022instead ofvnext-preview. Running locally does not seem to be an issue, but running on the Azure DevOps build agents is timing out.
Are there emulator logs from the pipeline you can share here? The newest vnext-preview release has different logs that the pipelines might not be expecting. Generally, the health server logs should be used to determine if the emulator has started up properly (these logs are also present in vnext-EN20251022), but if they are absent or showing "FAIL" continuously, then there is a startup issue here.
We began to see our pipelines failing yesterday afternoon. Today we were able to resolve the issue using this image
mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-EN20251022instead ofvnext-preview. Running locally does not seem to be an issue, but running on the Azure DevOps build agents is timing out.Are there emulator logs from the pipeline you can share here? The newest vnext-preview release has different logs that the pipelines might not be expecting. Generally, the health server logs should be used to determine if the emulator has started up properly (these logs are also present in vnext-EN20251022), but if they are absent or showing "FAIL" continuously, then there is a startup issue here.
I just got an update from one of our Devs:
I think the real problem actually a code issue on our end. We are waiting on a specific log message before we say the test container is ready. That couples the start of our tests with the implementation of logging within the image, so if that changes even if the image is good, then we won't consider it started. I'm running everything just fine with the new image locally.
So it sounds like exactly what you are describing @Ritvik-Jayaswal - we are working on updating and testing our initialization now
We began to see our pipelines failing yesterday afternoon. Today we were able to resolve the issue using this image
mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-EN20251022instead ofvnext-preview. Running locally does not seem to be an issue, but running on the Azure DevOps build agents is timing out.Are there emulator logs from the pipeline you can share here? The newest vnext-preview release has different logs that the pipelines might not be expecting. Generally, the health server logs should be used to determine if the emulator has started up properly (these logs are also present in vnext-EN20251022), but if they are absent or showing "FAIL" continuously, then there is a startup issue here.
I just got an update from one of our Devs:
I think the real problem actually a code issue on our end. We are waiting on a specific log message before we say the test container is ready. That couples the start of our tests with the implementation of logging within the image, so if that changes even if the image is good, then we won't consider it started. I'm running everything just fine with the new image locally.
So it sounds like exactly what you are describing @Ritvik-Jayaswal - we are working on updating and testing our initialization now
Yes, if there's a handholding on the correct startup signal, the up-to-date keyword should be (as in the image above too):
PostgreSQL=OK, Gateway=OK, Explorer=OK