fix(appsync): make contextual data accessible for async functions

[leandrodamascena]

Issue number: #5290

Summary

Changes

This PR addresses an issue where the App/Router context was not available when using AppSyncResolver with async functions. The problem stemmed from the context being cleared too early in the execution flow, specifically before async functions could access it.

This change allows the context to persist throughout the execution of async functions, ensuring that contextual data remains accessible when needed. However, it shifts the responsibility of context clearing to the developer for async functions to prevent potential data leaks or unintended data persistence between invocations.

We've also updated the documentation to clearly communicate this change to users, providing guidance on how to manually clear the context when using async resolvers.

This bug doesn't affect batch resolvers.

What I fixed:

1. Modifying the resolve method in the AppSyncResolver class class to detect if the response is a coroutine.
2. If the response is a coroutine (indicating an async function), the context is not cleared automatically.
3. For non-coroutine responses, the context continues to be cleared automatically for safety.

User experience

def test_route_context_is_manually_cleared_after_resolve_async():
    app = AppSyncResolver()

    mock_event = {"typeName": "Customer", "fieldName": "field", "arguments": {}}

    @app.resolver(field_name="field")
    async def get_async():
        app.context.clear()
        await asyncio.sleep(0.0001)
        return "value"

    # WHEN
    mock_context = LambdaContext()
    app.append_context(is_admin=True)
    result = app.resolve(mock_event, mock_context)

    # THEN
    assert asyncio.run(result) == "value"
    assert app.context == {}

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• Meet tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics

Is this a breaking change?

RFC issue number:

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.15%. Comparing base (c11d25c) to head (1696526).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #5317   +/-   ##
========================================
  Coverage    96.15%   96.15%           
========================================
  Files          229      229           
  Lines        10806    10807    +1     
  Branches      2006     2007    +1     
========================================
+ Hits         10391    10392    +1     
  Misses         327      327           
  Partials        88       88           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud