Re: [Zope] AssertionError after update to Zope 2.8.1
[Ricardo Newbery]
Oh so close...
Migrated from Zope 2.7.2 to 2.8.1 Updated all the Catalog instances according to the instructions. Fixed a few outdated products.
Then just for kicks, I tried to update the Python scripts by visiting the /manage_addProduct/PythonScripts/recompile url. After about a minute, it threw up an error page. This is what shows up in the log...
2005-08-21T01:56:45 ERROR txn.170046464 Error in abort() on manager <Connection at 0956724c> Traceback (most recent call last): File "/Zope-2.8/lib/python/transaction/_transaction.py", line 456, in _cleanup File "/Zope-2.8/lib/python/ZODB/Connection.py", line 348, in abort File "/Zope-2.8/lib/python/ZODB/Connection.py", line 360, in _abort AssertionError ------ 2005-08-21T01:56:45 ERROR Zope.SiteErrorLog http://someurl.com/manage_addProduct/PythonScripts/recompile Traceback (most recent call last): File "/Zope-2.8/lib/python/ZPublisher/Publish.py", line 119, in publish File "/Zope-2.8/lib/python/Zope2/App/startup.py", line 215, in commit File "/Zope-2.8/lib/python/transaction/_manager.py", line 84, in commit File "/Zope-2.8/lib/python/transaction/_transaction.py", line 381, in commit File "/Zope-2.8/lib/python/transaction/_transaction.py", line 379, in commit File "/Zope-2.8/lib/python/transaction/_transaction.py", line 424, in _commitResources File "/Zope-2.8/lib/python/ZODB/Connection.py", line 462, in commit File "/Zope-2.8/lib/python/ZODB/Connection.py", line 483, in _commit AssertionError
They both look like "the same" error: in both cases, a Connection is marching over its list of registered (modified) objects (to abort the current transaction in the first case, and to commit the current transaction in the second case), and in both cases it finds an object in the list that has never been assigned an oid (object id). Concretely, in the first case, this is the assert that's failing: for obj in self._registered_objects: oid = obj._p_oid assert oid is not None # HERE The second case is similar. Of course asserts should never trigger. It suggests that something, somewhere, is "cleverly" creating new objects in a flawed away, and they're getting caught.
Nothing appears to be broken yet but I'm wondering whether I should roll back to my backup. Anyone have any ideas about this error? I'm tempted to just pretend that I didn't see it.
That's up to you, but wishing away assert failures isn't recommended practice ;-) If you can find a finite way to reproduce it, please open a Zope bug report.
participants (1)
-
Tim Peters