Summary

• Implement automatic ASGI mode detection for functions decorated with @aio.http or @aio.cloud_event
• The approach creates a Flask app first, loads the module within its context, then checks if ASGI is needed
• This results in an unused Flask app for ASGI functions, but we accept this memory overhead as a trade-off
• The --asgi CLI flag still works and skips the Flask app creation for optimization

Implementation Details

• Added ASGI_FUNCTIONS set to _function_registry.py to track functions that require ASGI
• Updated @aio.http and @aio.cloud_event decorators to register functions in ASGI_FUNCTIONS
• Modified create_app() to auto-detect ASGI requirements after module loading:
  1. Always creates a Flask app first
  2. Loads the user module within Flask app context
  3. Checks if target function is in ASGI_FUNCTIONS registry
  4. If ASGI is needed, delegates to create_asgi_app_from_module()
• The --asgi CLI flag continues to work, bypassing Flask app creation entirely for performance

Trade-offs

• Memory overhead: ASGI functions will have an unused Flask app instance created during auto-detection
• Accepted trade-off: This avoids loading modules twice which could cause side effects
• Optimization available: Users can still use --asgi flag to skip Flask app creation entirely

Test plan

• Added tests to verify decorators register functions in ASGI_FUNCTIONS
• Added CLI tests to verify auto-detection works for @aio decorated functions
• Added CLI tests to verify regular functions still use Flask/WSGI mode
• Added proper test isolation with registry cleanup fixtures
• All existing tests pass
• Linting passes