pallets/flask · error · RuntimeError

There is no request in this context.

Error message

There is no request in this context.

What it means

In Flask 3.x the request and app contexts are merged into one `AppContext`; the context's `request` property (src/flask/ctx.py:370-379) raises this RuntimeError when `_request is None`, i.e. the context was created with `app.app_context()` rather than from an incoming HTTP request or `test_request_context()`. It marks the distinction between 'an app is active' and 'a request is being handled'.

Source

Thrown at src/flask/ctx.py:377

        .. versionchanged:: 1.1
            The current session data is used instead of reloading the original data.

        .. versionadded:: 0.10
        """
        return self.__class__(
            self.app,
            request=self._request,
            session=self._session,
        )

    @property
    def request(self) -> Request:
        """The request object associated with this context. Accessed through
        :data:`.request`. Only available in request contexts, otherwise raises
        :exc:`RuntimeError`.
        """
        if self._request is None:
            raise RuntimeError("There is no request in this context.")

        return self._request

    def _get_session(self) -> SessionMixin:
        """Open the session if it is not already open for this request context."""
        if self._request is None:
            raise RuntimeError("There is no request in this context.")

        if self._session is None:
            si = self.app.session_interface
            self._session = si.open_session(self.app, self.request)

            if self._session is None:
                self._session = si.make_null_session(self.app)

        return self._session

    @property

View on GitHub ↗ (pinned to 6a2f545bfd)

Solutions

  1. Use `with app.test_request_context('/path'): ...` instead of `app.app_context()` when the code under test reads `request`.
  2. Guard shared code with `flask.has_request_context()` and take a non-request path when False.
  3. Refactor helpers to accept request-derived values as parameters instead of reading the `request` proxy directly.

Example fix

# before
with app.app_context():
    print(request.path)  # RuntimeError: There is no request in this context.

# after
with app.test_request_context('/reports'):
    print(request.path)
Defensive patterns

Strategy: type-guard

Validate before calling

ctx = app.test_request_context("/")
ctx.push()  # ensure ctx.request exists before accessing it
try:
    method = ctx.request.method
finally:
    ctx.pop()

Type guard

from flask import has_request_context

def request_available() -> bool:
    return has_request_context()

Try / catch

try:
    req = ctx.request
except RuntimeError:
    req = None  # context has no bound request; obtain data another way

Prevention

When it happens

Trigger: Accessing `flask.request` (which proxies `app_ctx.request`) while only a plain app context is pushed: inside `with app.app_context()`, in `flask shell`, in CLI commands (`@app.cli.command`), or in teardown/background code that pushed an app context but has no request.

Common situations: Shared helper functions that read `request` being reused from CLI commands or scheduled jobs; extensions touching `request` during app-context-only initialization; tests that push `app.app_context()` when they actually need `app.test_request_context()`; code migrated from older Flask assuming separate context checks.

Related errors


AI-assisted analysis of pallets/flask@6a2f545bfd (2026-07-31). Data as JSON: /data/errors/4b8b4708b9ec1741.json. Report an issue: GitHub ↗.