Fix #905: Release the internally created IAsyncEnumerator

[izanhzh]

Fixes #905

Because the AsyncEnumerableWriteAdapter class internally creates an IAsyncEnumerator, it was not released in the end, causing the database access to be occupied.

This requires integration testing, and I am unable to provide unit tests. However, I can reproduce the issue, and after adjustment, it works fine on my side.

[gemini-code-assist]

Summary of Changes

Hello @izanhzh, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a significant resource management issue where asynchronous enumerators were not being properly disposed of, causing persistent database connection occupation. By implementing IAsyncDisposable in the relevant adapter and ensuring its invocation within the OpenXmlWriter, the change guarantees that resources are released promptly after use, improving application stability and preventing potential deadlocks or resource exhaustion.

Highlights

• Resource Leak Fix: Addressed a critical resource leak where internally created IAsyncEnumerator instances were not being released, leading to database access being occupied indefinitely.
• Asynchronous Disposal Implementation: The AsyncEnumerableWriteAdapter now implements IAsyncDisposable, providing a mechanism to properly dispose of its internal IAsyncEnumerator.
• Ensured Disposal in OpenXmlWriter: Modified the OpenXmlWriter to wrap the asynchronous writing process in a try-finally block, ensuring that DisposeAsync() is called on the asyncWriteAdapter when it implements IAsyncDisposable.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses a resource leak by ensuring the internally created IAsyncEnumerator is properly disposed. The implementation of IAsyncDisposable in AsyncEnumerableWriteAdapter and its consumption within a try...finally block in OpenXmlWriter is a solid approach to fixing the issue. The changes are well-focused and effective. I have one suggestion to simplify the code slightly.

[gemini-code-assist]

The check && genericArgument != null is redundant. The IsAsyncEnumerable extension method's implementation already guarantees that genericArgument will not be null if the method returns true. Removing this redundant check will make the code slightly cleaner.

        if (values.GetType().IsAsyncEnumerable(out var genericArgument))

[michelebastione]

I had tried doing the same thing by adding a using statement instead but I must have misscoped it because that didn't work, while this one does. Anyways, this is I think too minor of an edge case to start setting up a whole integration testing pipeline. Let's maybe consider it for the backlog.