Make testEnv AutoCloseable

[0xivanov]

🆕🐥 First Timers Only

This issue is reserved for people who have never contributed to Hedera or any open source project in general.
We know that creating a pull request (PR) is a major barrier for new contributors.
The goal of this issue and all other issues labeled by 'Good First Issue' is to help you make your first contribution to Hedera.

👾 Description of the issue

A gRPC channel (ManagedChannelImpl) is being garbage collected without properly shutting down, causing the following error:

SEVERE: *~*~*~ Previous channel ManagedChannelImpl{logId=13, target=127.0.0.1:50211} was garbage collected without being shut down! ~*~*~*
Make sure to call shutdown()/shutdownNow()
java.lang.RuntimeException: ManagedChannel allocation site

This occurs because the testing environment is not consistently being closed, leading to open gRPC channels that are not properly terminated. Failure to shut down the channels can result in resource leaks and instability in the tests.

Proposed Solution:

• To prevent this issue, make the IntegrationTestEnv class implement the AutoCloseable interface, so it can be automatically closed when the test finishes. This ensures that all gRPC channels are properly shut down, avoiding the need for manual calls to shutdown() or shutdownNow().

• Additionally, the initialization of the testing environment should be wrapped in a try-with-resources block. This will ensure that the environment is closed automatically after the test, preventing resource leaks and the improper garbage collection of gRPC channels.

📋 Step by step guide to do a contribution

If you have never contributed to an open source project at GitHub, the following step-by-step guide will introduce you to the workflow. More information and concrete samples for shell commands for each step can be found in our CONTRIBUTING.md file.
A more detailed general documentation of the GitHub PR workflow can be found here.

• Claim this issue: Comment below that you are interested in working on the issue
• Wait for assignment: A community member with the given rights will add you as an assignee of the issue
• Fork the repository: You can do that in GitHub (by simply clicking the 'fork' button).
• Check out the forked repository
• Create a feature branch for the issue. We do not have a hard naming definition for branches but it is best practice to prefix the branch name with the issue id.
• Solve the issue in your branch.
• Commit your changes: Here, it is needed to add sign-off information to the commit to accept the "Developer Certificate of Origin" (https://developercertificate.org). More details can be found in our CONTRIBUTING.md
• Start a Pull Request (PR): We have a pattern for naming pull requests that a GitHub Action checks. We use that pattern to support the creation of automatic release notes.
• Check GitHub Actions: Several GitHub Actions will be triggered automatically for each PR. If a GitHub Action fails and you do not understand the cause of that error do not hesitate to add a comment to the PR and ask the Hedera developer community for support.
• Wait for reviews: Members of the Hedera developer community will review your PR. If a reviewer finds any missing pieces or a problem, he or she will start a discussion with you and describe the next steps for solving the problem.
• You did it 🎉: We will merge the fix in the develop branch. Thanks for being part of the Hedera community as an open-source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a chance to receive cool goodies like a T-Shirt. 🎽

🤔 Additional Information

If you have any questions, just ask us directly in this issue by adding a comment. You can join our community chat at Discord. A general manual about open-source contributions can be found here.

[steffenboe]

hi there, i would like to contribute this!

[steffenboe]

just to get this straight: replacing the constructor call and associated call to the close()-method (416 occurrences in 217 files) with a try-with-resources block is part of this issue?

[hendrikebbers]

Oh, let's ask @0xivanov if we can split that up. Having 416 code places changed is a lot for a good first issue ;)

[0xivanov]

While touching multiple places, it is actually a good fit for beginners because the changes involve simple, well-defined adjustments rather than deep modifications in the SDK’s core functionality.

• The solution primarily involves adding an AutoCloseable implementation and wrapping existing code in try-with-resources blocks. These are straightforward modifications that don't require deep knowledge of the gRPC internals or complex SDK implementation details.
• The changes are isolated to test environments, meaning they're not touching the core logic of the SDK. It provides a clear learning opportunity without risking breaking critical parts of the system.
• The task is mostly repetitive, which can be helpful for newcomers. Once they understand the pattern, they can apply it across the codebase, gaining confidence while having a clear direction.

[steffenboe]

Its not a big Deal for me, i will not do this manually 😀 will try out vscode search&replace functionality with some regex magic to get it done, probably this week i will get to work on this

[hendrikebbers]

Great! I will assign you tomorrow when I’m back at my laptop @steffenboe

[SimiHunjan]

@hendrikebbers assigned!