[dotnet] [bidi] Initialize internal modules without Lazy

[nvborisenko]

User description

💥 What does this PR do?

Don't use Lazy<T> because it reserves a reference to all modules, which is not AOT friendly.

💡 Additional Considerations

Probably we want to make an initialization in Property (with locking to be thread-safe)?

🔄 Types of changes

• Cleanup (formatting, renaming)

---

PR Type

Other

---

Description

• Remove Lazy<T> initialization from BiDi modules for AOT compatibility

• Initialize modules directly in constructor instead of lazy loading

• Update property accessors to return modules directly

---

Changes diagram

flowchart LR
  A["Lazy<Module> fields"] --> B["Direct Module fields"]
  C["Lazy initialization"] --> D["Direct initialization"]
  E["Property.Value access"] --> F["Direct property access"]

Loading

---

Changes walkthrough 📝

	Relevant files
Enhancement	BiDi.cs Remove lazy initialization from BiDi modules                          dotnet/src/webdriver/BiDi/BiDi.cs Replace Lazy fields with direct module fields Initialize modules directly in constructor Update property accessors to return modules without .Value +24/-24

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[qodo-code-review]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Thread Safety The removal of Lazy initialization may introduce thread safety concerns if the BiDi class is accessed from multiple threads concurrently. The previous Lazy implementation provided thread-safe initialization, but direct field initialization in constructor doesn't guarantee thread-safe access to the modules themselves. private readonly Session.SessionModule _sessionModule; private readonly BrowsingContext.BrowsingContextModule _browsingContextModule; private readonly Browser.BrowserModule _browserModule; private readonly Network.NetworkModule _networkModule; private readonly Input.InputModule _inputModule; private readonly Script.ScriptModule _scriptModule; private readonly Log.LogModule _logModule; private readonly Storage.StorageModule _storageModule; Performance Impact All modules are now initialized eagerly in the constructor regardless of whether they will be used. This could impact startup performance and memory usage, especially if some modules are rarely used or have expensive initialization. _sessionModule = new Session.SessionModule(_broker); _browsingContextModule = new BrowsingContext.BrowsingContextModule(_broker); _browserModule = new Browser.BrowserModule(_broker); _networkModule = new Network.NetworkModule(_broker); _inputModule = new Input.InputModule(_broker); _scriptModule = new Script.ScriptModule(_broker); _logModule = new Log.LogModule(_broker); _storageModule = new Storage.StorageModule(_broker);

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Add exception handling for initialization Consider adding null checks or exception handling around module initialization. If any module constructor throws an exception, the BiDi object will be left in an inconsistent state with some modules initialized and others not. dotnet/src/webdriver/BiDi/BiDi.cs [45-52] -_sessionModule = new Session.SessionModule(_broker); -_browsingContextModule = new BrowsingContext.BrowsingContextModule(_broker); -_browserModule = new Browser.BrowserModule(_broker); -_networkModule = new Network.NetworkModule(_broker); -_inputModule = new Input.InputModule(_broker); -_scriptModule = new Script.ScriptModule(_broker); -_logModule = new Log.LogModule(_broker); -_storageModule = new Storage.StorageModule(_broker); +try +{ + _sessionModule = new Session.SessionModule(_broker); + _browsingContextModule = new BrowsingContext.BrowsingContextModule(_broker); + _browserModule = new Browser.BrowserModule(_broker); + _networkModule = new Network.NetworkModule(_broker); + _inputModule = new Input.InputModule(_broker); + _scriptModule = new Script.ScriptModule(_broker); + _logModule = new Log.LogModule(_broker); + _storageModule = new Storage.StorageModule(_broker); +} +catch +{ + _broker?.Dispose(); + throw; +} Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies that if a module constructor fails, the _broker object might not be disposed, leading to a resource leak; the proposed try-catch block is a robust solution.	Medium
Update

[RenderMichael]

Nice simplication!

[nvborisenko]

Thanks Nick and Mike!