[Zope-dev] Logging after ConflictError Retries

[Dieter Maurer]

Malcolm Cleaton wrote at 2005-6-9 10:13 +0100:
>After a ConflictError causes a request to be retried, a few things go a
>bit wrong with error handling and logging in the Zope server.
>
>1. If the request is abandoned after repeated ConflictErrors, no error at
>all appears in the error log.

Right: please file a bug report.

The fix is (almost surely) to replace in ".../Zope/App/startup.py":

   if t is ZPublisher.Retry: v.reraise()

by

   if t is ZPublisher.Retry: t, v, traceback = v._args

> ...
>2. If there is at least one ConflictError and then the request finishes
>with an error (either more ConflictErrors or something else), the Z2 log
>shows the request as having been answered with status 200, although
>actually a status 500 error response has been served.
>
>I've managed to work out what's causing this, but fixing may be more
>fiddly. What happens is, once the request is abandoned because of the
>error, when control comes back to publish_module_standard in Publish.py,
>response.exception() is called on the original response, not on the latest
>retry. Then, when HTTPResponse _finish() is called, it traces down to the
>latest retry to find the status code for the logging, which is now the
>wrong one.

This should only happen when "publish" itself raises an exception.
Usually, "publish" should *NOT* raise an exception, when
the request fails (although exceeding the maximal number
of retries may cause this).


Nevertheless, the mixed use of "response" and "request.response"
in "publish_module_standard"
looks wrong. Almost surely, "request.response" should
get the value of "response" when "publish" succeeds and
both are different.
Thus I expect, we should have:

     response = publish(...)
     request.response = response
  except ...


Please file two bug reports for the problems you discovered...

-- 
Dieter