I am seeing errors with optouts and unsubscribes similar to this. It is inconsistent - some requests succeed but some fail with "There was an error in your request" as described there. The query string on the optout or unsubscribe looks like: "jid=3292&qid=1930772&h=b600fd5ef64ce4b4". Doing a DB query I can find the matching 'id' and 'job_id' in the civicrm_mailing_event_queue table, but the hash does not match, so the attempt to verify the parameters produces the error. So it seems as though in these cases the hash value is either corrupted in transit or is overwritten in the database. I'd be interested to know if anyone else can validate that behavior. Thanks. This is on CiviCRM 5.43.0 and Wordpress 5.8.2, with flexmailer and mosaico enabled.

Edit: just to be clear, the returned hash value does not exist anywhere in the civicrm_mailing_event_queue table so I don't know how it is being generated.

  • I have a similar issue, except I can't even find the job_id in civicrm_mailing_event_queue! Sep 11, 2023 at 12:11
  • Now almost two years later I am still seeing these errors, so I started tracking them in a spreadsheet. I modified the code so the error message would contain the job, queue and hash IDs. Today a mailing went out to about 4,000 emails, and the opt-out page was hit 17 times so far. Two were successful and were recorded in the opt-out report. Six others had a bad hash ID but could be identified based on the queue ID. One had only a bad hash, and no other parameters. Four more have what appear to be random query strings, and the last 4 have no query strings after the reset parameter.
    – twowheeler
    Oct 20, 2023 at 21:26
  • Those last 9 seem likely to be automated abuse of some kind, but the six with two good parameters and a bad hash are the puzzle. The data is at docs.google.com/spreadsheets/d/…
    – twowheeler
    Oct 20, 2023 at 21:34
  • I hardly ever hear of people complaining that they can't unsubscribe. So hopefully this is just weirdness that comes from automated systems misbehaving - by accident or otherwise. It is annoying though! Oct 23, 2023 at 7:39
  • Well, I do hear such complaints. "Your unsubscribe doesn't work, I tried it 3 times." At that point they are writing an angry email to the director.
    – twowheeler
    Oct 23, 2023 at 9:45

1 Answer 1


It's hard to imagine how the hash could be corrupted in transit, but easier to imagine how it could be overwritten in the database. I recommend enabling advanced logging (Administer menu » System Settings » Misc) so that you can see the old values of records in log_civicrm_mailing_event_queue.

  • Since adding the 'report error' extnsion we are identifying a lot of these and are stumped with how to identify why some are going out without all the necessary parameters. will upgrade soon and see if that stops them but haven't spotted anything that suggests a fix has been done
    – petednz - fuzion
    Aug 4, 2023 at 4:43
  • @Jon G - Actually advanced logging does not help, because it ignores all of the civicrm_mailing_event_* tables. Which is probably a good thing since they would grow very large very quickly, but provides no clues in this situation.
    – twowheeler
    Oct 31, 2023 at 2:12
  • Ah - good point. But also this code is getting a major rewrite - the civicrm_mailing_event_* tables are going away soon, e.g. github.com/civicrm/civicrm-core/pull/27557. Might be worth reassessing in Civi 5.67 and 5.68. Oct 31, 2023 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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