openerp-india team mailing list archive

[Georges Racinet <1083724@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

The unit test "draw_twice_no_gaps" in openerp/tests/ir_sequence.py
expects an Operational Error to be raised for the second attempt, and
catches that error based on the error message with a regular exception :

        msg_re = '^could not obtain lock on row in relation "ir_sequence"$'
        with self.assertRaisesRegexp(psycopg2.OperationalError, msg_re):
            n0 = registry('ir.sequence').next_by_code(cr0, ADMIN_USER_ID, 'test_sequence_type_2', {})
            assert n0
            n1 = registry('ir.sequence').next_by_code(cr1, ADMIN_USER_ID, 'test_sequence_type_2', {})
        cr0.close()
        cr1.close()


Unfortunately, that error message can depend on locales (happens in the typical Debian french installation) and the regexp  in that case will not be fulfilled.

This has two consequences:
  - the test fails
  - the cursor aren't closed, because the exception hasn't been catched and these closings are in the test method itself. In turn, the test process then hangs, waiting indefinitely for those locks that have not been released, only SIGTERM can end it.


Fortunately, OperationalError also come along with an error code, that can be compared against constants in psycopg2.errorcodes (patch to be pushed)

Some of our buildslaves suffer from this, which makes the build erratic

** Affects: openobject-server
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/1083724

Title:
  Failing and blocking unit test on sequences

Status in OpenERP Server:
  New

Bug description:
  The unit test "draw_twice_no_gaps" in openerp/tests/ir_sequence.py
  expects an Operational Error to be raised for the second attempt, and
  catches that error based on the error message with a regular exception
  :

          msg_re = '^could not obtain lock on row in relation "ir_sequence"$'
          with self.assertRaisesRegexp(psycopg2.OperationalError, msg_re):
              n0 = registry('ir.sequence').next_by_code(cr0, ADMIN_USER_ID, 'test_sequence_type_2', {})
              assert n0
              n1 = registry('ir.sequence').next_by_code(cr1, ADMIN_USER_ID, 'test_sequence_type_2', {})
          cr0.close()
          cr1.close()

  
  Unfortunately, that error message can depend on locales (happens in the typical Debian french installation) and the regexp  in that case will not be fulfilled.

  This has two consequences:
    - the test fails
    - the cursor aren't closed, because the exception hasn't been catched and these closings are in the test method itself. In turn, the test process then hangs, waiting indefinitely for those locks that have not been released, only SIGTERM can end it.

  
  Fortunately, OperationalError also come along with an error code, that can be compared against constants in psycopg2.errorcodes (patch to be pushed)

  Some of our buildslaves suffer from this, which makes the build
  erratic

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/1083724/+subscriptions