post_process_request (again) following r6691
|Reported by:||osimons||Owned by:||osimons|
|Cc:||pacopablo@…, Noah Kantrowitz||Branch:|
 made some changes to
trac.web.main.RequestDispatcher._post_process_request() that has an unfortunate side-effect of not calling filters when errors occur.
If errors are detected, filters are just called as
self._post_process_request(req) which means that the argument count will never match, and hence no calls will actually be made.
As all filters for a long time has been able to handle calls with
None argument replacements, I suggest we revert this back partially so that whenever there is not a direct match on arguments ('normal' processing for same version filters), we call and pass
None arguments and discard the result.
The diff looks like this:
287 287 return chosen_handler 288 288 289 289 def _post_process_request(self, req, *args): 290 290 291 resp = args 291 292 for f in reversed(self.filters): 292 # as the arity of `post_process_request` has changed since 293 # Trac 0.10, we only call filters which have the same arity 294 if arity(f.post_process_request) - 2 == len(args): 293 # As the arity of `post_process_request` has changed since 294 # Trac 0.10, only filters with same arity gets passed real values. 295 # Other calls are made with None arguments (including error 296 # situations that call without arguments), and results not saved. 297 extra_arg_count = arity(f.post_process_request) - 2 298 if extra_arg_count == nbargs: 295 299 resp = f.post_process_request(req, *resp) 300 301 296 302 return resp 297 303 298 304
OK to commit?
Change History (10)
follow-up: 2 comment:1 by , 12 years ago
|Priority:||normal → high|