Duplicate nid creation when making forum topics and adding to organic groups

Hi,

I got the same problem in Workflow 6.x-1.1, Drupal 6.10 with og forum (pathauto active but not used for forum entries):

user warning: Duplicate entry '237' for key 1 query: INSERT INTO forum (tid, vid, nid) VALUES (105, 237, 172) in
/modules/forum/forum.module on line 281.

Replying to myself:

I solved this as follows:
When I configure Workflow actions to my workflow in admin/build/trigger/workflow/1, Trigger automatically adds a "Save post" action to every configured action that changes something to a post (e.g. unpublish it).

This action is causing the error, even if I have only the "Save Post" action configured, not only if there are two actions (unpublish & save).

If I unassign this "save post" action, the error disappears.

This seems to be duplicate of #472966: Avoid execute_transition twice (when using Rules, Actions)

j4h8 her solution/workaround also worked for me.

Thanks for sharing. It was a though one to catch.

I am not able to solve this problem with j4h8 solution however if you disable the create revision option from content type it removes the warnings.

Is it the right solution.

I tried the patch referenced at #472966: Avoid execute_transition twice (when using Rules, Actions), but it did not fix it for me. I'm also experiencing this with OG Actions and Workflow module.

j4h8's workaround does indeed get rid of the error, but what you'll discover if you're using the "Add post to group" action (or at least what I'm seeing here) is that when you edit the newly-created node, the group it was supposed to be added to isn't checked in the list of groups. This is because without that "Save post" action, og_nodeapi op insert never fires, so the og_ancestry table doesn't get populated. This is despite the node_access table having the proper information in it. Very bizarre.

Something else that's interesting is I can trigger this condition without Workflow, and just with Trigger module, Trigger Unlock (to make "Save post" available at the same time as OG), OG actions, and the "Save post" action.

I'm trying to decide between a 2-hour step-debugging session through the guts of triggers/actions and just writing a hook_workflow() op transition post and saying to hell with it.

Oh-ho. That's not exactly true!

When I use Trigger Unlock + Trigger + "Add post to the foo group" + "Save post" + "Trigger: After saving a new post", I get the duplicate key entry.
When I remove "Save post", I no longer get the error, and the post shows up in the group as intended.

When I use Workflow + Trigger Unlock + Trigger + "Add post to the foo group" + "Save post" + "Trigger: (creation) => State 1", I get the duplicate key entry.
When I remove "Save post", I no longer get the error, but the post also does not show up in the group.

Well, good! Narrowed it down to just one of the 11,000 possible things triggering the bug. :P I guess I'll start tossing breakpoints around in workflow_nodeapi then.

Brave decision to debug this. Good luck!

Dear lord what a pain in the ass.

Here's the short version: This happened to me because og_access has a weight of 1, and workflow has a weight of 0. Workflow's save post action triggers a node_save() inside a node_save() which confuses the hell out of OG Access and causes it to insert the record twice. Increasing workflow's weight to 1 in the system table solves the issue.

Now, if you care about the nitty-gritty details... here's how it works:

1. New post is created. It calls node_save() op 'insert'.
2. node_save() goes through and does its thing. La, dee, dah... $node gets saved to the database and comes back with a populated $node->nid property.
3. node.module now goes through and calls hook_nodeapi op insert, telling all modules a node just got added.
4. Oh, look! It's hook_workflow_nodeapi('insert')! Let's see what it wants to do... What's that? And now you want to call node_save() again? Well, sure! Why not?!
5. Oh, except that $node->nid is already set, so we must be doing *update* logic now, huh?
6. og_access_nodeapi op update checks to see if we have an nid in the og_access_post table yet. Nope, we sure don't! Let's go ahead and add one then.
7. La, dee, dah... oh say there! We never did finish that node_save() op *insert* before, did we? Let's continue on...
8. Oh, look! OG Access has a weight of 1. That means we didn't cover it before we called the node_save() in workflow module. Let's do!
9. This triggers og_nodeapi op insert, which will insert the record again for good measure...
10. BOOM.

So the solution, after all of that? One fricking line of SQL:

UPDATE system SET weight = 1 WHERE name = 'workflow';

This will ensure OG Access's insert logic gets called *before* Workflow's (because they're at the same weight, and O comes before W), so when this nesting happens the row in og_post_access will already be there and og_nodeapi op update won't try and add it again.

MAARRRGGGHHH! :P Hope this saves someone else several hours of hair-pulling.

I wonder if it's worth a patch to workflow module to set its weight to 10 or something, for good measure.

Forgot to mention: Thanks to miro_dietiker at http://drupal.org/node/472966#comment-2571890 for throwing me a bone that got me hunting in the generally right direction.

I am getting this error too on nodes that are OG content types where I have a workflow that is offers an option of "Draft." The error doesn't happen when the author chooses "Publish This," where I have a rule that publishes the node. The error does happen when "draft" is chosen. It does not matter that the OG post is public or not.

For example: When I create a node under my content type "Announcement" I get an error with workflow and OG involving the same issues with

user warning: Duplicate entry '758' for key 1 query: INSERT INTO og_access_post (nid, og_public) VALUES (758, 1) in /var/www/public_html/includes/common.inc on line 3477.

Despite the error the post seems to be there but, when I look at the database, entry 758 is not even there, but I can see the node at value 759.

INSERT INTO `content_type_announcement` VALUES ('1165','759','<p>Body of Gbla Goobla.</p>','4',null,null,null);
INSERT INTO `node` VALUES ('759','1165','announcement','','Gbla Goobla','1','0','1271181187','1271181187','2','0','0','0','0','0');
INSERT INTO `node_revisions` VALUES ('759','1165','1','Gbla Goobla','','','','1271181187','0');

Webchick's observations fit perfectly, while the implications of the fix are unclear to me. Would this fix be permanent?

It seems to be a special case problem and I saw the other posts about drupal 8 that talk about the same thing. It was about how core should handle weight, which is over my head. Much of the core coding and module specific code is over my head.


If someone could break down Webchick's solution in a few sentences I would be highly grateful. Do I change a workflow weight value somewhere to 1 in the database or change a line in workflow module? Or is there a pending fix for this?


I tried to look at the diffs of the workflow module. I didn't see anything that looked like Webchick's fix.

#9 is the smart answer for anyone skipping to the bottom of this discussion.

To put my question more clearly: After I run that SQL command, will I need to make any additional changes later upon updating Workflow? Will the weight stick? Should I wait for a patch?

I experienced a similar issue when using Workflow 6.x-1.4 + Rules 6.x-1.2 or even just Workflow + Triggers. I'm not even using OG.

I was trying to do was trigger an action when Workflow state changes to/from live to publish/unpublish the node. It always threw a duplicate key error on XML Sitemap module if I changed workflow state in the same transaction as creating the node (on node edit page). I didn't see this problem if I kept the initial state in a workflow state that wouldn't trigger the event, saved the new node, then edited the node again upping the workflow state to start the trigger.

However, even though I didn't get the duplicate key error from XML Sitemap using that 2-step method, I did notice in my View showing user's unpublished nodes and workflow state, I would always see a duplicate node displayed when I changed workflow states back and forth using the node edit page causing it to trigger publish/unpublish. I found that if I changed workflow states using the Workflow tab instead of the node edit, I didn't get this duplication.

After much searching and banging my head on the wall, post #9 (webchick) seems to have helped. (THANKS!!) Except, instead of increasing the weight of workflow to 1, on both workflow entries in the system table I had to increase them to 21, which is heavier than both XML Sitemap and Rules.

I have no idea if changing the weight so much is going to cause other problems though! O_o

If you are new to running MYQL from the command line. This is the step by step procedure of how I made the changes.

Log in to your webserver using ssh that has the mysql database on it.

At the prompt login to mysql with a user with the proper privileges to change the database.

$mysql -u root -p

You will be prompted for your mysql password. In this case I logged in as mysql user root. If you are unsure what the name of your databases is you can type the following:

mysql> show databases;

Which will yield something like this:

+--------------------+
| Database |
+--------------------+
| information_schema |
| database_1 |
| database_2 |
| mysql |
+--------------------+

switch to the database that you want to make the change in.

mysql> use database_2

mysql will tell you that you have changed to the database. If you are still unsure what database you are in you can type:

mysql> showtables;

That will list all of the database tables.

Following the directions listed my webchick at #9 you can update the weight of workflow by typing:

mysql> UPDATE system SET weight = 1 WHERE name = 'workflow';

or in the case of augie at #13

mysql> UPDATE system SET weight = 21 WHERE name = 'workflow';

Still getting the same issue with 6.x-1.4 (and Organic Groups). Webchick's solution at #9 fixes it...

I think this warrants "Critical" till a patch lands (anyone?), probably in the .install file, as it will break any site it occurs on...

db_query("UPDATE {system} SET weight = '1' WHERE name = 'workflow'");

I followed the recommendation for changing the weight and I'm still getting duplicate comments in my workflow using 6.x-1.4 Any other ideas?

Webchick explains the problem well at comment #9. http://drupal.org/node/309974#comment-2594564

However, I didn't have workflow enabled, and I couldn't determine which module causing the problem so in the end the fix I used was to reduce the weight of the OG modules ensuring that og_access was still slightly heavier. If anyone knows a reason why this shouldn't be done please comment below.

UPDATE system SET weight = weight - 10 WHERE name = 'og_access';
UPDATE system SET weight = weight - 10 WHERE name = 'og_actions';
UPDATE system SET weight = weight - 10 WHERE name = 'og_notifications';
UPDATE system SET weight = weight - 10 WHERE name = 'og_views';

Which took the values of weight on my system to:

og_access = -9
og_actions = -10
og_notifications = -10
og_views = -10

Further details here:
http://www.clearlysecure.com.au/node/84

patch with git notes! (http://groups.drupal.org/node/161659) – contributions duly noted

Moving all remaining issues to D7.

Moving this back to D6-version.
We have moved to D7. Please open a new issue if you hencounter the same problem. You will not have this problem when using Workflow Field in D7.