fix: check async generator

[TonyPythoneer]

Approaching the issues

Closes dapr/js-sdk#604

Root cause

I reviewed the code at this link and printed the result object if the Dapr Workflow function runs it. The output is as follows:

result: AsyncGenerator { _invoke: [Function (anonymous)] }
result.toString(): [object Object]

Based on the MDN documentation, this doesn't seem like the correct way to check if an object is an AsyncGenerator.

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/asyncIterator#try_it
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncGenerator#asyncgenerator.prototypesymbol.tostringtag

To properly check if result is an AsyncGenerator, we should use:

const isAsyncGenerator = typeof result[Symbol.asyncIterator] === 'function';

This approach is more reliable and aligns with the standard practices for identifying AsyncGenerator objects. Once this check is corrected, the workflow function should work as expected.

My thought

I opted not to write a test for this change because the new method, typeof result[Symbol.asyncIterator] === 'function', is more theoretically correct and robust than the previous string-based approach because:

1. Direct Check: It directly checks for the presence of Symbol.asyncIterator, which is the defining characteristic of an async generator. This ensures we are accurately identifying async generators.
2. Theoretical Correctness: The use of typeof to check for the existence of the async iterator method aligns with the theoretical underpinnings of JavaScript, making the check more reliable and less prone to errors due to changes in object string representations.

Given that the new implementation is a more theoretically correct and robust method for identifying async generators, I believe that writing a test for this specific change might not be necessary. The new method improves the accuracy and reliability of the check without introducing additional complexity or potential points of failure.

Additionally, the robustness of the new method implies that it inherently handles the scenarios we care about, reducing the need for extensive testing compared to the previous string-based approach.

---

Feel free to adjust any part of this if needed!

[TonyPythoneer]

@kaibocai @cgillum @XavierGeerinck @microsoftopensource
Are you available to review my PR?

Thank you!

[XavierGeerinck]

Thank you for the extensive research on this! Happy to merge it in