[Bug]: WithAcceptLicenseAgreement is not working for Azure ServiceBus Emulator

[bhehe]

Testcontainers version

4.10.0

Using the latest Testcontainers version?

Yes

Host OS

Windows

Host arch

x86

.NET version

9.0

Docker version

[ ACTUALLY PODMAN HERE ]

Client:
 Version:           29.1.3
 API version:       1.52
 Go version:        go1.25.5
 Git commit:        f52814d
 Built:             Fri Dec 12 14:51:52 2025
 OS/Arch:           windows/amd64
 Context:           default

Server: linux/amd64/fedora-42
 Podman Engine:
  Version:          5.6.1
  APIVersion:       5.6.1
  Arch:             amd64
  BuildTime:        2025-09-03T20:00:00-04:00
  Experimental:     false
  GitCommit:        1e2b2315150b2ffa0971596fb5da8cd83f3ce0e1
  GoVersion:        go1.24.6
  KernelVersion:    6.6.87.2-microsoft-standard-WSL2
  MinAPIVersion:    4.0.0
  Os:               linux
 Conmon:
  Version:          conmon version 2.1.13, commit:
  Package:          conmon-2.1.13-1.fc42.x86_64
 OCI Runtime (crun):
  Version:          crun version 1.23.1
commit: d20b23dba05e822b93b82f2f34fd5dada433e0c2
rundir: /run/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  Package:          crun-1.23.1-1.fc42.x86_64
 Engine:
  Version:          5.6.1
  API version:      1.41 (minimum version 1.24)
  Go version:
  Git commit:
  Built:
  OS/Arch:          linux/amd64
  Experimental:

Docker info

Client:
 Version:    29.1.3
 Context:    default
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 3
 Server Version: 5.6.1
 Storage Driver: overlay
  Supports shifting: true
  Supports volatile: true
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  Using metacopy: true
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge macvlan ipvlan
  Log: k8s-file none passthrough journald
 Swarm: inactive
 Runtimes: crun-vm kata runc runj runsc youki crun crun-wasm krun ocijail
 Default Runtime: crun
 Init Binary:
 containerd version:
 runc version:
 init version:
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 6.6.87.2-microsoft-standard-WSL2
 Operating System: fedora
 OSType: linux
 Architecture: amd64
 CPUs: 22
 Total Memory: 15.35GiB
 Name: LMX11XISXLT016
 ID: 158796ff-1227-4cbb-8158-5cf4f41428e7
 Docker Root Dir: /var/lib/containers/storage
 Debug Mode: false
 Experimental: true
 Live Restore Enabled: false
 Product License: Apache-2.0
 Default Address Pools:
   Base: 10.89.0.0/16, Size: 24
   Base: 10.90.0.0/15, Size: 24
   Base: 10.92.0.0/14, Size: 24
   Base: 10.96.0.0/11, Size: 24
   Base: 10.128.0.0/9, Size: 24

What happened?

Attempting to use ServiceBus Emulator for first time. I have SQL Server module working fine so I know TestContainers and Podman are playing together for basic functionality. This appears to be an issue with the 'builder' itself versus running the emulator I believe.

Beyond the convenience method, which I see was a recent addition, I tried just setting the environment variable directly, tried multiple variants for the value (t, T, True, TRUE, Y, y, Yes, YES, etc). Nothing seems to get around that check. I even added it to my test.runsettings file (though that wouldn't impact the actual emulator code running in the container this seems to be occurring before it's running - it's when you BUILD the container instance not in StartAsync itself).

Relevant log output

Message: 
System.ArgumentException : The image 'mcr.microsoft.com/azure-messaging/servicebus-emulator:latest' requires you to accept a license agreement. (Parameter 'Image')

  Stack Trace: 
<>c__DisplayClass63_0.<ValidateLicenseAgreement>b__2(ArgumentInfo`1 argument)
Guard.ThrowIf[TType](ArgumentInfo`1& argument, Func`2 condition, Func`2 ifClause)
ContainerBuilder`3.ValidateLicenseAgreement()
ServiceBusBuilder.Build()

Additional information

Would be interested if there's any temporary hacks or workarounds otherwise, this is deal-breaker for my current efforts to demonstrate using TestContainers to improve our integration testing for our eventing/messaging based apps.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• [Bug]: ServiceBusContainer does not start and throws Timeout exception on Windows #1466
• [Bug]: System.TimeoutException: 'The operation has timed out.' #1478
• [Bug]: System.InvalidOperationException : Exposed port 8081/tcp is not mapped. #1449
• [Bug]: Testcontainers.MsSql npipe:////pipe/<any pipe> is not a valid npipe URI #1571
• [Bug]: Basic example from docs throw exception: Method not found: 'Docker.DotNet.DockerClient...' #1425

🔗 Related PRs

#1576 - feat: Support configuring Docker API version [merged]
#1583 - feat: Add KurrentDb module [merged]
#1605 - docs: Pin the image version explicitly [merged]
#1606 - chore: Set remaining container image explicit [merged]

👤 Suggested Assignees

• HofmeisterAn
• joeymedina
• VladislavAntonyuk
• mm-srtr
• cezarlamann

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[digital88]

The tests are working fine in GHA, could you share code where you setup builder?

[bhehe]

My code snippet:

When stepping into the Build() method I can see the environment variable doesn't seem to be set/passed at all...

Then using the direct environment variable setting approach instead of the convenience method I see the same outcome:

[bhehe]

At first I was curious and thinking if using Podman instead of Docker could somehow be complicit here but that doesn't seem likely given it's the C# builder code that's barking, but that's a variable.

I checked the tests to compare my code and to find out how the new constructor args for image name were being dealt with and if any constants were made available as I hit both of these matters today as I tried getting the latest versions to see if that resolved this matter.

[digital88]

My code snippet:

Can you write it like this and try? :

var builder = new (...)
.WithAcceptLicenseAgreement(true)
.WithLogger()
.WithConfig();

Builder is immutable and should be chained. Or reassign variable builder every time.

[bhehe]

ok, the fluent/chaining would make sense if it's losing state. Trying that now.

[bhehe]

Bingo. That was the magic sauce! Not sure how you could guard/defend for that type of user error or make it more painfully obvious that you MUST use the fluent chain. I didn't expect that for sure as when I try to debug/step into code that is built with fluent (optional) method chaining I do that to ease the debugging pain and then sometimes put it back to a single call.

Thanks for the super timely responses!