Duplicate fid-node key error when flagging content

i was having this bug too, here is a patch of my solution.

I was experiencing the same error, the patch above seemed to solve this problem.

Hi

Please commit this

From documentation for update queries: http://drupal.org/node/310080

The execute() method will return the number of rows affected by the query. Note that affected is not the same as matched. In the above query, an existing record that already has a uid of 5 and status of 1 will be matched, but since the data in it does not change it will not be affected by the query and therefore not be counted in the return value. As a side effect, that makes Update queries ineffective for determining if a given record already exists.

Scaling to major as 500 errors on live sites is a NO NO NO

Thanks jodarove for the patch and nirbhasa for reporting the problem. I discovered this issue separately as part of #1258282: Logging in after anonymous flagging may cause duplicate entry SQL errors, but it doesn't look like I got the syntax for a db_merge() query correct. I've committed this patch that fixes the current 7.x-2.x branch to match your approach, which is correct.

I had the same issue in carnity.org for flagging content with anonymous user, so used the above patch and problem resolved.

Now new problem appear, that might have been there before but i just noticed today. When anonymous user flag content and do the comparison and content stay flagged, then if anonymous user wants to login then it shows similar type of PDO error but in flag.module. Can you please help resolving this bug???? Thanks in advance.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2-7-1-0' for key 'fid_content_id_uid_sid': UPDATE {flag_content} SET uid=:db_update_placeholder_0, sid=:db_update_placeholder_1 WHERE (uid = :db_condition_placeholder_0) AND (sid = :db_condition_placeholder_1) ; Array ( [:db_update_placeholder_0] => 1 [:db_update_placeholder_1] => 0 [:db_condition_placeholder_0] => 0 [:db_condition_placeholder_1] => 20 ) in flag_user_login() (line 573 of /home/thehighb/public_html/carnity.org/sites/all/modules/flag/flag.module).

Same too me
thanks

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-38' for key 1: INSERT INTO {flag_counts} (fid, content_type, content_id, count) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => node [:db_insert_placeholder_2] => 38 [:db_insert_placeholder_3] => 1 ) en flag_flag->_update_count() (línea 738 de ../drupal/sites/all/modules/flag/flag.inc).

Same problem with me.

I was also having this problem, but I noticed that beta6 was getting old (September last year), so I tried 2.x-dev and the error is gone. Marking this fixed.

this worked with beta7, doesn't work with beta8

regression in beta8, test case missing. (how? mink?)

It can't be the exact same error, as there is no longer a flag_flag->_update_count() method.

Can you obtain the error output please?

this is setting flag with session_api as anonymous user (through a rule, if it matters):

PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'sid' at row 1: INSERT INTO {flag_content} (fid, content_type, content_id, uid, sid, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => node [:db_insert_placeholder_2] => 7 [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => -1 [:db_insert_placeholder_5] => 1343380456 ) in flag_flag->_flag() (line 753 of /home/daniele/Documenti/LinguisticStudio/rafaels/sites/all/modules/flag/flag.inc).

If I'm reading that correctly, the sid is being set to -1?

That comes from flag_set_sid(). Not sure how that could end up with a -1. Could you do some debugging?

Possibly related to this issue: #1619114: After cleaning cookies, flagging content as an anonymous user causes a PDO exception.
We only got this PDO exception after cleaning cookies, but that may have changed with recent commits, haven't tested.

maybe i found something ..
adding
$create = TRUE;

at line 2041 of flag.module, make it works again

function flag_set_sid($uid = NULL, $create = TRUE) {
  static $sids = array();

  if (!isset($uid)) {
    $uid = $GLOBALS['user']->uid;
  }

  if (!isset($sids[$uid])) {
    if (module_exists('session_api') && session_api_available() && $uid == 0) {
      $create = TRUE; // this fix the problem
      $sids[$uid] = session_api_get_sid($create);
    }
    else {
      $sids[$uid] = 0;
    }
  }

  return $sids[$uid];
}

also I think there is no reason to be FALSE there

a.ross I miss your comment, yes it's that, i copied the comment there, close this if ok

> close this if ok

No, please don't!

Issues are only closed when the bug is fixed. That means a patch has to be written and committed to the module's code repository. Otherwise, working with a module involves a horrendous amount of patching for everyone, which would be insane!

      $create = TRUE; // this fix the problem
      $sids[$uid] = session_api_get_sid($create);

Could someone investigate whether perhaps the spec for session_api_get_sid() has changed for version 7? Why does passing FALSE give us a bad sid?

http://drupalcode.org/project/session_api.git/blob/refs/heads/7.x-1.x:/s...

 56 else if (!$create) {
57 // Return a negative value here, since it won't collide with any
58 // session_api IDs.
59 return -1;
60 }

So a -1 is normal behaviour on 7.

In fact, it's normal in 6 too: http://drupalcode.org/project/session_api.git/blob/refs/heads/6.x-1.x:/s...

So the next question is: why are we not requesting a session to be created? Should we? If not, and we don't have a session ID, what should be done?

Also, I notice that your error message is UTTERLY different from the original one in this bug!

Setting this back to closed. Please file a new one with the latest findings!