We get these a couple of times a week. I doubt it's a big deal, but it triggers Nagios, and we should be working to put KARL "on ice" so to speak, so shutting these up could help.
I believe this is a design decision Shane made to have indexing happen in an asynchronous PG commit or something.
If possible, just handle the exception and log it to as info, thus shutting up Nagios.
IntegrityError: (psycopg2.IntegrityError) duplicate key value violates unique constraint "archived_item_pkey"
DETAIL: Key (container_id, namespace, name)=(84910621, , data-collection-form-advisory-boards.doc) already exists.
[SQL: 'INSERT INTO archived_item (container_id, namespace, name, docid) VALUES (%(container_id)s, %(namespace)s, %(name)s, %(docid)s)'] [parameters: {'namespace': u'', 'container_id': 84910621, 'docid': -1486955278, 'name': u'data-collection-form-advisory-boards.doc'}]
Exception when processing https://karl.soros.org/communities/contract-online-replacement/files/data-collection-forms/add_file.html
Referer: https://karl.soros.org/communities/contract-online-replacement/files/data-collection-forms/add_file.html
Traceback (most recent call last):
File "/srv/osfkarl/.buildout/eggs/cp27mu/pyramid-1.2.1-py2.7.egg/pyramid/tweens.py", line 17, in excview_tween
response = handler(request)
File "/srv/osfkarl/.buildout/eggs/cp27mu/pyramid_tm-0.5-py2.7.egg/pyramid_tm/__init__.py", line 107, in tm_tween
return response
File "/srv/osfkarl/.buildout/eggs/cp27mu/pyramid_tm-0.5-py2.7.egg/pyramid_tm/__init__.py", line 73, in __exit__
return self._retry_or_raise(*sys.exc_info())
File "/srv/osfkarl/.buildout/eggs/cp27mu/pyramid_tm-0.5-py2.7.egg/pyramid_tm/__init__.py", line 60, in _retry_or_raise
reraise(t, v, tb) # otherwise reraise the exception
File "/srv/osfkarl/.buildout/eggs/cp27mu/pyramid_tm-0.5-py2.7.egg/pyramid_tm/__init__.py", line 69, in __exit__
self.manager.commit()
File "/srv/osfkarl/.buildout/eggs/cp27mu/transaction-2.1.2-py2.7.egg/transaction/_manager.py", line 131, in commit
return self.get().commit()
File "/srv/osfkarl/.buildout/eggs/cp27mu/transaction-2.1.2-py2.7.egg/transaction/_transaction.py", line 310, in commit
reraise(t, v, tb)
File "/srv/osfkarl/.buildout/eggs/cp27mu/transaction-2.1.2-py2.7.egg/transaction/_transaction.py", line 301, in commit
self._commitResources()
File "/srv/osfkarl/.buildout/eggs/cp27mu/transaction-2.1.2-py2.7.egg/transaction/_transaction.py", line 446, in _commitResources
reraise(t, v, tb)
File "/srv/osfkarl/.buildout/eggs/cp27mu/transaction-2.1.2-py2.7.egg/transaction/_transaction.py", line 418, in _commitResources
rm.tpc_begin(self)
File "/srv/osfkarl/.buildout/eggs/cp27mu/zope.sqlalchemy-0.6.1-py2.7.egg/zope/sqlalchemy/datamanager.py", line 87, in tpc_begin
self.session.flush()
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 2019, in flush
self._flush(objects)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 2137, in _flush
transaction.rollback(_capture_exception=True)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/util/langhelpers.py", line 60, in __exit__
compat.reraise(exc_type, exc_value, exc_tb)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 2101, in _flush
flush_context.execute()
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/unitofwork.py", line 373, in execute
rec.execute(self)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/unitofwork.py", line 532, in execute
uow
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/persistence.py", line 174, in save_obj
mapper, table, insert)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/orm/persistence.py", line 767, in _emit_insert_statements
execute(statement, multiparams)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 914, in execute
return meth(self, multiparams, params)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/sql/elements.py", line 323, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement
compiled_sql, distilled_params
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1146, in _execute_context
context)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception
exc_info
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/util/compat.py", line 200, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1139, in _execute_context
context)
File "/srv/osfkarl/.buildout/eggs/cp27mu/SQLAlchemy-1.0.12-py2.7-linux-i686.egg/sqlalchemy/engine/default.py", line 450, in do_execute
cursor.execute(statement, parameters)
IntegrityError: (psycopg2.IntegrityError) duplicate key value violates unique constraint "archived_item_pkey"
DETAIL: Key (container_id, namespace, name)=(84910621, , data-collection-form-advisory-boards.doc) already exists.
[SQL: 'INSERT INTO archived_item (container_id, namespace, name, docid) VALUES (%(container_id)s, %(namespace)s, %(name)s, %(docid)s)'] [parameters: {'namespace': u'', 'container_id': 84910621, 'docid': -1486955278, 'name': u'data-collection-form-advisory-boards.doc'}]
No, this is repozitory.
I'm 98% repozitory and pgtextindex don't integrate with two-phase commit properly. This could explain an error like this one, as well as issues I've seen with pgtextindex.
Unfortunately, this surfaces as an exception in a way that I don't think we'd want to ignore. In general, I wouldn't want to ignore integrity errors and the code involved is all generic. There is no KARL code in the traceback.
To be a broken record -- sorry! -- nagios is a poor fit for this. Nagios is all about state, not errors. If errors were handled by sentry, it would be easy to silence this (by not resolving it). I suppose the Nagios plugin could be hacked to ignore this, but I expect that plugin is generic as well.
Another option would be to modify repozitory to use upserts.