Is using Google Cloud Tasks to invoke an internal Django endpoint effectively asynchronous (even under WSGI)?
I'm running a Django application on Google Cloud Run using the default WSGI-based setup (e.g., Gunicorn/ runserver for local dev).
To avoid blocking during long-running operations like third-party API calls, I'm planning to use Google Cloud Tasks.
Current design:
A request comes in to a Django endpoint (e.g., a webhook or ping from an external service)
Instead of processing the request inline, I enqueue a Cloud Task
That task posts to another Django endpoint within the same service, which performs the third-party API call using data passed in the task payload
This means:
I'm not offloading the work to a separate Cloud Run service
The fetch logic is still part of the same Django service/container, just decoupled by the task
My question:
Does this setup allow the third-party call to be effectively asynchronous (i.e., non-blocking to the original request), despite using WSGI and not ASGI or Celery?
When searching around, I mostly see articles and examples where Cloud Tasks are used to call a separate Cloud Run service, not another internal route in the same app.
Is this internal invocation pattern valid and scalable under WSGI, or are there caveats I should be aware of?