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
@propertyView on GitHub ↗ (pinned to 6a2f545bfd)
Solutions
- Use `with app.test_request_context('/path'): ...` instead of `app.app_context()` when the code under test reads `request`.
- Guard shared code with `flask.has_request_context()` and take a non-request path when False.
- 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
- Access `request` only after a request context has been pushed (inside a view, or inside `with app.test_request_context():`).
- In tests, use the `with` form of `test_request_context` so push/pop are always balanced.
- Don't stash context objects and read their `.request` attribute later from another execution flow.
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
- Working outside of request context. Attempted to use functi
- 'after_this_request' can only be used when a request context
- 'copy_current_request_context' can only be used when a reque
- Working outside of application context. Attempted to use fu
- The session is unavailable because no secret key was set. S
AI-assisted analysis of pallets/flask@6a2f545bfd (2026-07-31).
Data as JSON: /data/errors/4b8b4708b9ec1741.json.
Report an issue: GitHub ↗.