2

I have a few contacts in CiviCRM 4.7.27 for which changes in the "edit contact" form are not saving. The update queries are being sent to MySQL correctly, but they're in a transaction which is being being ended by a ROLLBACK statement, which obviously undoes the changes.

For all other contacts, changes save just fine, with no ROLLBACK.

Example queries from a single "Save" form submission:

UPDATE  civicrm_contact  SET contact_type = 'Individual' , contact_sub_type = NULL , sort_name = 'jones, jennifer' , display_name = 'jennifer jones' , first_name = 'jennifer'   WHERE (  civicrm_contact.id = 3198 );
UPDATE  civicrm_uf_match  SET domain_id = 1 , uf_id = 6839 , uf_name = 'jnphillips_22@msn.com' , contact_id = 3198   WHERE (  civicrm_uf_match.id = 2754 );
UPDATE civicrm_group g SET    cache_date = NULL, refresh_date = NULL WHERE  g.cache_date <= '20180503151700';
UPDATE civicrm_setting SET value = 'LnnjD1Un' WHERE name='navigation' AND contact_id IS NOT NULL;
UPDATE civicrm_contact SET  email_greeting_custom = NULL , email_greeting_display = 'Dear jennifer', postal_greeting_custom = NULL , postal_greeting_display = 'Dear jennifer', addressee_custom = NULL , addressee_display = 'jennifer jones' WHERE id = 3198;
... (and lots of delete/insert on civicrm cache tables.)

How can I track down the source and cause of this ROLLBACK statement?

  • Is there a common pattern between contacts that work and those that don't? Can you create a new contact and step by step duplicate the information that is in another contact until it no longer saves? – Luke Stewart May 7 '18 at 4:46
  • TwoMice you always have the most fun puzzles. This would be a good one for "Bring your problem" day at the Civi MeetUp. – jackrabbithanna May 11 '18 at 23:25
  • hit me up on mattermost if you want to bounce ideas – jackrabbithanna May 11 '18 at 23:27
  • Using a particular MySQL flavor like MariaDB or Percona? Version? – jackrabbithanna May 11 '18 at 23:32
0

No errors of any kind, it's just when you get back to contact summary, the data hasn't changed? Strange if that's the case, you'd expect an exception to be thrown.

Are those queries you posted the full list? Have you done a side by side comparison of all queries?

It looks like there are several methods in /CRM/Core/Transaction.php that execute a rollback.

Those may be places that you could run var_dump(debug_backtrace()) and look for differences, write it to a file if you have to.

Another thing to try would be to copy all the sql statements, and run them outside of civi, like in mysql directly, or a mysql client, and see if you get an error message from that.

Your not getting anything about database locks in a log are you? https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-detection.html

0

Here's how I found what was causing the rollback:

  1. Grepped the codebase to find that CRM_Core_Transaction::rollback() is where a transaction is marked for rollback; there may be any number of good reasons to do this, for example, when using the api parameter 'force_rollback'
  2. Used xdebug with my IDE (netbeans) to get the execution backtrace from this point in the code, trying to find where and why it was called.
  3. Following that backtrace, I finally noticed that on this Joomla site, the Joomla plugin CiviCRM Group Sync was what made the api call for which this transaction was marked for rollback.

Other notes:

  • I'm not 100% confident this is a bug in the "CiviCRM Group Sync" plugin, because I've been unable to create reproduction steps, e.g., I could not create a contact and cause it to have this bad behavior.
  • The workaround was to temporarily disable the plugin, then make any change to the contact, then re-enable the plugin. Users can now make edits to this contact as usual, without this bad behavior.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.