fix(ServiceBus): Ignore runtime property to support reuse

[franciscosamuel]

What does this PR do?

Makes the configuration hash of ServiceBusContainer stable by removing the IDatabaseContainer from the hashed configuration.

Why is it important?

The IDatabaseContainer contains runtime information about the database container such as the start time which changes everytime, resulting in an always changing configuration hash, which breaks the Resource Reuse feature for ServiceBus containers.

Related issues

• Relates [Bug]: Resource Reuse doesn't work for ServiceBusContainer #1642

How to test this PR

Since this concerns cross-execution tests, an automated test would become quite convoluted. The easiest way to test this is to temporarily modify the configurations on ServiceBusCustomMsSqlConfiguration and DatabaseFixture to both use .WithReuse(true) and running the test twice. The first execution should create the containers and the second should reuse them.

Follow-ups

An analogous change needs to be made for EventHubs. I will do it in a separate PR

Summary by CodeRabbit

• Chores
  • Improved Service Bus configuration JSON serialization handling to prevent unintended property export.

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	443ebea
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-dotnet/deploys/69a5c2f71330210008368f4a
😎 Deploy Preview	https://deploy-preview-1643--testcontainers-dotnet.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Walkthrough

Added [JsonIgnore] attribute to the DatabaseContainer property in ServiceBusConfiguration to exclude it from JSON serialization, with the necessary System.Text.Json.Serialization using directive imported globally.

Changes

Cohort / File(s)	Summary
JSON Serialization Configuration src/Testcontainers.ServiceBus/ServiceBusConfiguration.cs, src/Testcontainers.ServiceBus/Usings.cs	Added [JsonIgnore] attribute to DatabaseContainer property and imported System.Text.Json.Serialization namespace to prevent the DatabaseContainer from being serialized.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Suggested labels

bug

Suggested reviewers

• HofmeisterAn

Poem

🐰 A rabbit hops through JSON streams,
Where properties hide in serialization dreams,
DatabaseContainer now sleeps unseen,
Marked with [JsonIgnore] so pristine! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description covers all required template sections: 'What does this PR do?', 'Why is it important?', 'Related issues', 'How to test this PR', and 'Follow-ups', providing clear context about the configuration hash fix.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title describes fixing an issue with resource reuse in ServiceBus by ignoring a runtime property that was causing configuration hash instability.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[HofmeisterAn]

Thanks for the contribution!

Something came to mind while I was thinking about this again. It's probably best to use the reuse hash from the actual dependent container instead of ignoring it.

We can merge this for now to unblock your use case, and then add it properly as a feature in a separate PR.

[franciscosamuel]

I didn't mention it in the issue, but while investigating I also thought of that and my thought process was:

1. the ReuseHash is calculated at the configuration level
2. the configuration only knows about the container itself, not its configuration
3. we are already relying on the user to pass in a configured container in order to use the Resource Reuse feature

So I believe this is actually the correct way to do it, at least until we have a pattern to pass down WithReuse to dependant containers.