The `should_ignore_error()` method was added in f191809 to support
context preservation for debugging, but it no longer serves its
original purpose and adds unnecessary overhead.
Issues with the current implementation:
- Always returns False by default
- Called on every single request with no benefit
- The original intention for error ignoring during debugging is not
how context preservation works anymore
- No documentation beyond API reference
- No tests for the functionality
- No evidence of real-world usage
Changes:
- Add deprecation warning to App.should_ignore_error() that will be
removed in Flask 4.0
- Optimize call site to only invoke the method if it's been overridden
by a subclass, eliminating the function call overhead for 99.9% of
requests
- Add comprehensive tests for the deprecation behavior
- Update CHANGES.rst with deprecation notice
Teardown handlers should manage their own error handling instead of
relying on this method.
Fixes#5816
When the 'flask' command is used with only the '--help' parameter, this
change will make sure to try and load the app before the help callback
is run. This was previously only being done when the 'flask' command was
used by itself. This meant when passing in '--help', any custom commands
were not getting shown in the help message. With this change, custom
commands will be included in the help message when running 'flask' on
the command line by itself or with the '--help' parameter.
By default Flask will provide responses to OPTIONS requests that are
automatically generated. These responses list the valid methods in the
response headers. Whilst this is useful, it can be frowned on by
auditors hence an ability to disable it wholesale is useful.
