API errors on webform

Can you reproduce this on your test server? If so, I would enable civicrm debugging option and maybe add a debug statement into the wf_civicrm_api function to get some more info.
Agree that "unknown error" is not particularly useful.

They're deadlocks:

Dec 10 09:50:15  [info] $backTrace = #0 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/CRM/Core/Error.php(770): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 [internal function](): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/PEAR.php(931): call_user_func((Array:2), Object(DB_Error))
#3 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB.php(969): PEAR_Error->PEAR_Error("DB Error: unknown error", -1, 16, (Array:2), "INSERT INTO civicrm_activity_contact (activity_id , contact_id , record_type_...")
#4 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/PEAR.php(564): DB_Error->DB_Error(-1, 16, (Array:2), "INSERT INTO civicrm_activity_contact (activity_id , contact_id , record_type_...")
#5 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB/common.php(1905): PEAR->raiseError(NULL, -1, NULL, NULL, "INSERT INTO civicrm_activity_contact (activity_id , contact_id , record_type_...", "DB_Error", TRUE)
#6 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB/mysql.php(898): DB_common->raiseError(-1, NULL, NULL, NULL, "1213 ** Deadlock found when trying to get lock; try restarting transaction")
#7 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB/mysql.php(327): DB_mysql->mysqlRaiseError()
#8 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB/common.php(1216): DB_mysql->simpleQuery("INSERT INTO civicrm_activity_contact (activity_id , contact_id , record_type_...")
#9 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB/DataObject.php(2421): DB_common->query("INSERT INTO civicrm_activity_contact (activity_id , contact_id , record_type_...")
#10 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/packages/DB/DataObject.php(1055): DB_DataObject->_query("INSERT INTO civicrm_activity_contact (activity_id , contact_id , record_type_...")
#11 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/CRM/Core/DAO.php(278): DB_DataObject->insert()
#12 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/CRM/Activity/BAO/ActivityContact.php(63): CRM_Core_DAO->save()
#13 /var/www/html/prod/drupal-7.34/sites/default/civicrm_custom_php/CRM/Activity/BAO/Activity.php(375): CRM_Activity_BAO_ActivityContact::create((Array:3))
#14 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/api/v3/Activity.php(162): CRM_Activity_BAO_Activity::create((Array:13))
#15 /var/www/html/prod/drupal-7.34/sites/all/modules/civicrm/api/api.php(88): civicrm_api3_activity_create((Array:9))
#16 /var/www/html/prod/drupal-7.34/sites/all/modules/webform_civicrm/includes/utils.inc(1251): civicrm_api("activity", "create", (Array:9))
#17 /var/www/html/prod/drupal-7.34/sites/all/modules/webform_civicrm/includes/wf_crm_webform_postprocess.inc(1171): wf_civicrm_api("activity", "create", (Array:7))
#18 /var/www/html/prod/drupal-7.34/sites/all/modules/webform_civicrm/includes/wf_crm_webform_postprocess.inc(220): wf_crm_webform_postprocess->processActivity()
#19 /var/www/html/prod/drupal-7.34/sites/all/modules/webform_civicrm/webform_civicrm.module(218): wf_crm_webform_postprocess->postSave(Object(stdClass))
#20 [internal function](): webform_civicrm_webform_submission_insert(Object(stdClass), Object(stdClass))
#21 /var/www/html/prod/drupal-7.34/includes/module.inc(895): call_user_func_array("webform_civicrm_webform_submission_insert", (Array:2))
#22 /var/www/html/prod/drupal-7.34/sites/all/modules/webform/includes/webform.submissions.inc(143): module_invoke_all("webform_submission_insert", Object(stdClass), Object(stdClass))
#23 /var/www/html/prod/drupal-7.34/sites/all/modules/webform/webform.module(3044): webform_submission_insert(Object(stdClass), Object(stdClass))
#24 /var/www/html/prod/drupal-7.34/includes/form.inc(1513): webform_client_form_submit((Array:33), (Array:23))
#25 /var/www/html/prod/drupal-7.34/includes/form.inc(903): form_execute_handlers("submit", (Array:33), (Array:23))
#26 /var/www/html/prod/drupal-7.34/includes/form.inc(385): drupal_process_form("webform_client_form_227", (Array:33), (Array:23))
#27 /var/www/html/prod/drupal-7.34/includes/form.inc(130): drupal_build_form("webform_client_form_227", (Array:23))
#28 /var/www/html/prod/drupal-7.34/sites/all/modules/webform/webform.module(1863): drupal_get_form("webform_client_form_227", Object(stdClass), FALSE, FALSE)
#29 [internal function](): webform_node_view(Object(stdClass), "full", "en")
#30 /var/www/html/prod/drupal-7.34/includes/module.inc(895): call_user_func_array("webform_node_view", (Array:3))
#31 /var/www/html/prod/drupal-7.34/modules/node/node.module(1440): module_invoke_all("node_view", Object(stdClass), "full", "en")
#32 /var/www/html/prod/drupal-7.34/modules/node/node.module(1335): node_build_content(Object(stdClass), "full", "en")
#33 /var/www/html/prod/drupal-7.34/modules/node/node.module(2670): node_view(Object(stdClass), "full", NULL)
#34 /var/www/html/prod/drupal-7.34/modules/node/node.module(1465): node_view_multiple((Array:1), "full")
#35 /var/www/html/prod/drupal-7.34/modules/node/node.module(2762): node_show(Object(stdClass))
#36 [internal function](): node_page_view(Object(stdClass), "REDACTED")
#37 /var/www/html/prod/drupal-7.34/includes/menu.inc(517): call_user_func_array("node_page_view", (Array:2))
#38 /var/www/html/prod/drupal-7.34/index.php(21): menu_execute_active_handler()
#39 {main}

In the case above there's an entry in log_civicrm_activity for an insert at the exact time above, done under the cid identified in the corresponding watchdog entry.

Edit: And strangely enough, no such record in civicrm_activity itself.

I'm seeing the below that looks like it could be related. The contact does not get created.

The CiviCRM "contact create" API function returned the error: "DB Error: constraint violation" when called by line 558 of wf_crm_webform_postprocess.inc with the following parameters: "Array ( [contact_type] => Individual [contact_sub_type] => Array ( ) [webform_label] => Contact Info [prefix_id] => 7 [first_name] => Joe [last_name] => Testing [source] => Contact Scott [check_permissions] => [version] => 3 ) "

PHP 5.4 and Civi 4.5.5 - Same behavior with both webform_civicrm production and dev versions

Any ideas here? Yikes!

Those api params look perfectly normal to me. Try running that in the api explorer and see what happens.

Gosh - I have no idea what running something in the API explorer might be; sadly, I'm a designer and not a coder. Below is the backtrace - perhaps this is a different issue than what FutureFirstJohn and FutureFirstDave are seeing? If so, I'm happy to open a different thread. Still stuck here... thanks!

$backTrace = #0 /home/scottweiss/public_html/sites/all/modules/civicrm/CRM/Core/Error.php(866): CRM_Core_Error::backtrace("backTrace", TRUE) #1 [internal function](): CRM_Core_Error::exceptionHandler(Object(DB_Error)) #2 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/PEAR.php(931): call_user_func((Array:2), Object(DB_Error)) #3 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB.php(975): PEAR_Error->PEAR_Error("DB Error: constraint violation", -3, 16, (Array:2), "INSERT INTO civicrm_log (entity_table , entity_id , data , modified_id , modi...") #4 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/PEAR.php(564): DB_Error->DB_Error(-3, 16, (Array:2), "INSERT INTO civicrm_log (entity_table , entity_id , data , modified_id , modi...") #5 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB/common.php(1905): PEAR->raiseError(NULL, -3, NULL, NULL, "INSERT INTO civicrm_log (entity_table , entity_id , data , modified_id , modi...", "DB_Error", TRUE) #6 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB/mysql.php(899): DB_common->raiseError(-3, NULL, NULL, NULL, "1452 ** Cannot add or update a child row: a foreign key constraint fails (`sc...") #7 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB/mysql.php(328): DB_mysql->mysqlRaiseError() #8 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB/common.php(1216): DB_mysql->simpleQuery("INSERT INTO civicrm_log (entity_table , entity_id , data , modified_id , modi...") #9 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB/DataObject.php(2442): DB_common->query("INSERT INTO civicrm_log (entity_table , entity_id , data , modified_id , modi...") #10 /home/scottweiss/public_html/sites/all/modules/civicrm/packages/DB/DataObject.php(1060): DB_DataObject->_query("INSERT INTO civicrm_log (entity_table , entity_id , data , modified_id , modi...") #11 /home/scottweiss/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(455): DB_DataObject->insert() #12 /home/scottweiss/public_html/sites/all/modules/civicrm/CRM/Core/BAO/Log.php(139): CRM_Core_DAO->save() #13 /home/scottweiss/public_html/sites/all/modules/civicrm/CRM/Contact/BAO/Contact.php(233): CRM_Core_BAO_Log::register(16, "civicrm_contact", 16) #14 /home/scottweiss/public_html/sites/all/modules/civicrm/CRM/Contact/BAO/Contact.php(320): CRM_Contact_BAO_Contact::add((Array:16)) #15 /home/scottweiss/public_html/sites/all/modules/civicrm/api/v3/Contact.php(409): CRM_Contact_BAO_Contact::create((Array:16)) #16 /home/scottweiss/public_html/sites/all/modules/civicrm/api/v3/Contact.php(103): _civicrm_api3_contact_update((Array:10), NULL) #17 /home/scottweiss/public_html/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(86): civicrm_api3_contact_create((Array:9)) #18 /home/scottweiss/public_html/sites/all/modules/civicrm/Civi/API/Kernel.php(95): Civi\API\Provider\MagicFunctionProvider->invoke((Array:9)) #19 /home/scottweiss/public_html/sites/all/modules/civicrm/api/api.php(25): Civi\API\Kernel->run("contact", "create", (Array:9), NULL) #20 /home/scottweiss/public_html/sites/all/modules/webform_civicrm/includes/utils.inc(1428): civicrm_api("contact", "create", (Array:9)) #21 /home/scottweiss/public_html/sites/all/modules/webform_civicrm/includes/wf_crm_webform_postprocess.inc(579): wf_civicrm_api("contact", "create", (Array:7)) #22 /home/scottweiss/public_html/sites/all/modules/webform_civicrm/includes/wf_crm_webform_postprocess.inc(138): wf_crm_webform_postprocess->createContact((Array:11)) #23 /home/scottweiss/public_html/sites/all/modules/webform_civicrm/webform_civicrm.module(202): wf_crm_webform_postprocess->preSave(Object(stdClass)) #24 /home/scottweiss/public_html/sites/all/modules/webform/includes/webform.submissions.inc(122): webform_civicrm_webform_submission_presave(Object(stdClass), Object(stdClass)) #25 /home/scottweiss/public_html/sites/all/modules/webform/webform.module(3266): webform_submission_insert(Object(stdClass), Object(stdClass)) #26 /home/scottweiss/public_html/includes/form.inc(1513): webform_client_form_submit((Array:33), (Array:24)) #27 /home/scottweiss/public_html/includes/form.inc(903): form_execute_handlers("submit", (Array:33), (Array:24)) #28 /home/scottweiss/public_html/includes/form.inc(385): drupal_process_form("webform_client_form_12", (Array:33), (Array:24)) #29 /home/scottweiss/public_html/includes/form.inc(130): drupal_build_form("webform_client_form_12", (Array:24)) #30 /home/scottweiss/public_html/sites/all/modules/webform/webform.module(1930): drupal_get_form("webform_client_form_12", Object(stdClass), FALSE, FALSE) #31 [internal function](): webform_node_view(Object(stdClass), "full", "en") #32 /home/scottweiss/public_html/includes/module.inc(895): call_user_func_array("webform_node_view", (Array:3)) #33 /home/scottweiss/public_html/modules/node/node.module(1440): module_invoke_all("node_view", Object(stdClass), "full", "en") #34 /home/scottweiss/public_html/modules/node/node.module(1335): node_build_content(Object(stdClass), "full", "en") #35 /home/scottweiss/public_html/modules/node/node.module(2670): node_view(Object(stdClass), "full", NULL) #36 /home/scottweiss/public_html/modules/node/node.module(1465): node_view_multiple((Array:1), "full") #37 /home/scottweiss/public_html/modules/node/node.module(2762): node_show(Object(stdClass)) #38 [internal function](): node_page_view(Object(stdClass)) #39 /home/scottweiss/public_html/includes/menu.inc(517): call_user_func_array("node_page_view", (Array:1)) #40 /home/scottweiss/public_html/index.php(21): menu_execute_active_handler() #41 {main}

I have another site using Civi 4.5.2 and production version 4.9 that's working just fine using the same settings/configuration. So I suspect either:

1. A change in Civi, or...

2. Perhaps a setting in the new site's server environment - it could be that I'm using PHP 5.3 on the working site and PHP 5.4 on the new site.

I had to use 5.4 on the new site on account of the following issue with Civi extensions:

http://forum.civicrm.org/index.php?topic=35066.0

Perhaps this will help - in any event, thanks to Coleman for all the work he's doing and... Merry Christmas!

OK - I downgraded to PHP 5.3 and there's no change - I get:

The CiviCRM "contact create" API function returned the error: "DB Error: constraint violation" when called by line 579 of wf_crm_webform_postprocess.inc with the following parameters: "Array ( [contact_type] => Individual [contact_sub_type] => Array ( ) [webform_label] => Contact Info [prefix_id] => 2 [first_name] => Juanita [last_name] => Testing [source] => Contact Scott [check_permissions] => [version] => 3 ) "

The contact doesn't get created. I'm running Civi 4.5.5 - any ideas? Gosh, I am stumped...

Hi bcobin, not sure if this will help much, but you can find the API explorer in CiviCRM here: [yoursite]/civicrm/api/explorer

The API explorer lets you test out API calls, which is what the webform module is making to add/change data in CiviCRM. It's a reasonably intuitive interface, so you should be able to use it to test out the API call that is failing. Try creating a contact:

Entity: contact, Action: create
Contact type = Individual
First name = ...
etc.

If the API call works then that would point more to an issue with the webform CiviCRM module, if the API call doesn't work then that suggests a problem with your setup.

Are you getting the errors on every submission, or only intermittently?

John,

Wow - thanks! This is super-helpful! Very, very cool...

On the problem site, which is running 4.5.5, I see no parameters after "Contact is in Trash" (save for "Other...")

On a working site running 4.4.5, there are many more parameters available, including Primary Email, which comes after "Contact is in Trash" and is thus unavailable on the problem site. So if there were requested parameters that are not available, I could see why creating contacts would fail.

Here's the "good" news - sort of: I see the same issue on the Civi demo site, which is running 4.5.6. I'm no expert here, but wouldn't that explain the problem? In other words, there's an API change that would cause 4.4 functionality here to fail in 4.5? Perhaps you could verify on the Civi demo site and better identify what's going on.

Pending this issue (plus another that has to do with extensions), I haven't upgraded any other sites to 4.5 yet, and I'm now really glad. I'd bet that downgrading to 4.4 on the new site would solve it, and that's what I plan to do.

Let me know what you think - this looks like a major Civi issue to me. Thanks again eversomuch... you rock!

Next step would be to investigate the CiviCRM JIRA issue queue to see if this has already been mentioned. However, I'm looking at the CiviCRM demo site (which is currently in Spanish) and there are lots of parameters showing up here: http://d45.demo.civicrm.org/civicrm/api/explorer

So I'm a bit baffled. I'll leave this issue open until it has a more appropriate home. Maybe you could post the issue in the CiviCRM forum bcobin, that would give people a chance to discuss the issue?

Thanks, John - not being an expert here, I'd like try to narrow this down in the interest of resolving the issue soonest.

The first image is from a 4.4 install - note the additional parameters after Contact is in Trash.

The second is from the Civi demo site. The selector is now a dropdown, so you can't see all the options simultaneously - note how many parameters are missing after Contact is in Trash.

This doesn't look right to me. Among the missing are parameters like email, which could explain why the process fails.

There's no user-facing error message upon failure to create the contact - I only noticed it when I was testing a new site and saw that the contact wasn't added to the assigned group. So users who have upgraded to 4.5 may be experiencing the same thing without knowing about it - they'd only see it if they verified that the user was created or if they checked the error log. I'd say this qualifies as a major issue.

Let me know what you think and I'll be happy to post this in the right place - you have been a HUGE help here...

I think the differences between the 4.4 api explorer and the 4.5 api explorer (which underwent a significant UI rewrite) may be a red herring here. The real question is "what is the constraint violation in your db and why is it happening?" The fact that it's happening on one of your sites but not the other two (regardless of PHP version or Civi version as you've said above) suggests that your one site's db may be corrupt. That might not be as scary as it sounds.

I have been using 4.5 with this module in my testing environment for nearly a year so I don't think your theory that 4.5 is inherently incompatible is correct.

One obvious thing to check (the only constraint I can think of in the api params you pasted in comment #9) is prefix_id. Check to see that this copy of civi really does contain an individual prefix with id 2.

Thanks, Coleman - much appreciated.

The new site is a very low-traffic site and I can easily track any form submissions simply using the webform results, so Civi is no big deal for this particular site at this point. I imported the Civi db from the dev site to the production site (as opposed to doing a "fresh" instal and then importing) - this has been problematic in recent Civi versions, so I'll take a look at the tables, but then I'll probably just do a fresh install of 4.5 and reproduce what little data there is on the existing site on the new install.

But I think that still leaves the issue of the new API explorer - it doesn't look like there's any way to test creating a contact with an email, which I don't think can be right. My main concern is upgrading existing sites to 4.5, which I'll pass on until I know more, I guess.

Thanks again - I will report back in the next day or two...

Everything in the new api explorer is generated from "getfields" api metadata. So this is just a shortcoming of api.getfields. It would be great to fix it, and in the meantime that's why there's an "other" option - you can just type in "email" yourself and proceed with exploring the api.

Thanks, Coleman - understood.

Check to see that this copy of civi really does contain an individual prefix with id 2.

The field exists in the table and I've tested with a variety of options here (Dr., Mrs., etc.) without success, so I don't think that's it.

The fact that it's happening on one of your sites but not the other two... suggests that your one site's db may be corrupt. That might not be as scary as it sounds.

I've checked the db in cPanel and everything checks out OK - I don't see any other way of testing it that's within my skill set.

Any additional guidance would be appreciated, but I think I'm going to punt at this point insofar as it's a tiny site where I can currently get along without Civi. For future sites, I suppose I'll need to stick with 4.4 until there's a resolution here - this is a super-simple site, but the first site where I've used 4.5 and the failure here scares the daylights out of me. Oh, well..

For future sites, I suppose I'll need to stick with 4.4 until there's a resolution here

There is still no problem btw Civi 4.5 and this module that I am aware of needing to be resolved. It works fine for me and everyone else who I know of who uses it. I don't know what went wrong with your particular site but I don't think it's indicative of the general state of the software. Don't lose hope :)

I am, in general, a hopeful person. So, like a dog with a bone...

API explorer checked out - to cut to the chase, it looks like this is an issue with the Civi MailChimp extension. Once I disabled it, everything worked just fine.

It should be noted that the Civi extension was the only MailChimp-related functionality that was enabled; there was nothing on the Drupal side.

Insofar as simple new module installation is not supposed to change existing functionality, this looks like an issue for the Civi MailChimp people and I'll look to file a report with them. In the meantime, sorry for sending everyone on a wild goose chase. Thanks for the help and, Coleman, for all the work you do and for the hopeful words! You rock...

Update: See http://forum.civicrm.org/index.php/topic,35521.0.html

Bad news: I upgraded the site to 5.4 and the error returns - contact isn't created. I am utterly at a loss at this point.

This is a small site that I'm using test configuration prior to updating existing sites to PHP 5.4 and Civi 4.5. So I'm stuck with 5.3 (which I understand is reaching end of life) and Civi 4.4 until I can resolve this. I can deal with just the web form submission on this site, but that won't fly for others.

Any guidance greatly appreciated… arrrgh...

So you're saying that a specific error was being caused by the mailchimp module under php 5.3, and disabling that module fixed it. Then when you upgraded to 5.4 that caused the exact same error? Sorry but I find that very hard to believe. I mean, I believe you that you are getting these errors, but the exact same error caused by two completely unrelated (I mean, as unrelated as anything can possibly be) things? Sounds very far fetched. Maybe there's some other factor, like your server does this whenever it's raining outside.

FYI I run php 5.4 on my sandbox without any trouble.

Yeah - I know it doesn't make any sense, but I swear that's what's happening. Your work as been impeccable on all of this stuff and heaven know you have your hands full and I don't want to bug you (or anyone), but i don't know what else to do.

Maybe there's some other factor, like your server does this whenever it's raining outside.

It has snowed a lot recently.

Seriously, I'm happy to give you full login creds if you'd like to take a look. I'm using webform_civicrm happily on a lot of other sites, so I'm not a n00b - I'm, just stumped on this one. Arrrgh!

Unfortunately I just don't have time to poke into every misbehaving server. It's not really my area of expertise either.

Thanks, Coleman - I get it. Let me see if the host can provide some insight and if so, I'll report back here and otherwise leave you alone. Thanks, as always!

I had the same error. I believe I have found the cause.

The issue occurs when a form submission fails and the user attempts to resubmit. The first time it could be something random. For example in our case we had the form set to create an activity. The activity assignment email could not be sent because the mail server was down. This caused the whole contact create to get rolled back. In the original poster's case the server may have been failing sometimes under load.

What seems to happen is that webform has already created a cookie that includes the contact id. I did not confirm this by tracking down where in the code the cookie gets set. It looks like it is webform and not in this module. This contact does not exist because the transaction was rolled back. Now when the user attempts to resubmit the form it tries to pass the non-existent cid as the modified_id to the civicrm_log function. This causes the constraint violation.

Clearing the cookies allows the next submissions to properly create a contact.

Ooh, progress :)

It may help with your debugging to know that contact id is not stored in cookies/session variables by this module, but it is stored in the database. Check the webform_civicrm_submissions table.

See this related issue.

This issue was filed against a branch (7.x-4.x) that is no longer supported. We're sorry we did not get to work through it, but once you upgrade to 7.x-5.x and if the issue persists, please feel free to re-open.