Wrong response code logged after ConflictError retries

[Malcolm Cleaton]

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.

[Malcolm Cleaton (malcolmcleaton)]

On the mailing list, Dieter investigated further:

A nasty workaround may be, to call "response.exception"
for the repeated request as well.
In order not to make implementations assumptions,
this should be done in "Zope.App.startup.zpublisher_exception_hook":

  The complete block starting with

        try:
            log = aq_acquire(published, '__error_log__', containment=1)

  and ending just before the "finally:"

  may be wrapped into a

      try:
        <block>
      except:
        response = getattr(REQUEST, 'response', None)
 if response is not None:
     response.exception()
 raise

Of course, the complete handling is so complex that is cries
out for simplification rather than further nasty workarounds...

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.