1

I just recently switched over to mac for work and am working on getting my local environment set up. Everything's been going much more smoothly than on my PC with Virtualbox, but when I go running bin/magento setup:upgrade for the first time I get the following error:

Installing data... Unable to save new cookie. Error: Unique constraint violation found

Installing data... Unable to save new cookie. Error: Unique constraint violation found

This is the result of going to magento2.docker/

Unable to run setup:upgrade

I'm running the enterprise cloud 2.3.4 on docker. It seems that this might possibly be the result of duplicate tables. I'm using the exact same DB as I previously was on Ubuntu so unless something corrupted during the transfer I don't see why it would be an issue with the DB dump. I haven't run into this error before and unfortunately haven't found an exact example with the same context as mine, although I'm sure someone here must have an idea. Thanks!

UPDATE (08/03/20):

Running DELETE FROM amasty_gdprcookie_cookie WHERE 1; running bin/magento setup:db-upgrade -vvv to check for errors, then re-running bin/magento setup:upgrade did the trick. Thanks for everyone's help!

Improve this question
4
  • I'd checked permissions with your system that session can be created.. it may be not really only magento issue
    – Herve Tribouilloy
    Jul 8, 2020 at 18:04
  • I just double checked my permissions and while inside docker, everything is root which is correct. Anything more specific I should look for?
    – Terence Patane-Ronan
    Jul 8, 2020 at 18:11
  • I have not used docker in a while but for what I have used either docker or vagrant, the problem of permissions was often happening. I'd verify a basic php page can create session to get yourself confident. Usually, we'd want the webserver owner to create the session and therefore should session folder not belong to the webserver owner?
    – Herve Tribouilloy
    Jul 8, 2020 at 18:14
  • Looks like the permissions are ok at this point, I'm able to pull up the nginx page and pretty much the error remains that the schema needs to be updated. I've updated my post with a screenshot of what happens when I try going to magento2.docker/. Still haven't found out what exactly is preventing me from running ```bin/magento setup:upgrade``, but once I do I'll update this post. To anyone else reading this, any further input would be appreciated!
    – Terence Patane-Ronan
    Jul 9, 2020 at 14:41

1 Answer 1

Reset to default
0

I had the same issue. I managed to debug this and I found that the module does not check if the cookies table already has data before inserting the initial cookies.

This happens when you run bin/magento setup:upgrade after you imported a database dump. The solution was to empty the amasty_gdprcookie_cookie table and run again the command.

Have a nice day

Improve this answer
5
  • I had a feeling it was something along those lines. My lazy workaround was to just disable my amasty_gdpr for the meantime since this is just for local dev, but your solution sounds much more complete. I'll try this and update with my results shortly. Thanks!
    – Terence Patane-Ronan
    Jul 22, 2020 at 19:55
  • Just as an update, I tried clearing the table and re-running the setup:upgrade command, and for some reason I'm running into the same issue with the same exact error message. Is there a step that I'm missing maybe?
    – Terence Patane-Ronan
    Jul 27, 2020 at 17:03
  • Hi, The steps I made were: - Run php bin/magento setup:db-data:upgrade to see the actual error - This way I saw that the Item that initial setup was trying to insert was already in the amasty_gdprcookie_cookie table. - I ran DELETE FROM amasty_gdprcookie_cookie WHERE 1; - Then I ran the setup command again; and it worked.
    – user10508084
    Jul 29, 2020 at 8:10
  • Or maybe TRUNCATE TABLE amasty_gdprcookie_cookie; is more suitable...
    – user10508084
    Jul 29, 2020 at 16:22
  • Awesome, it works! Since I already cleared the table manually last time, TRUNCATE TABLE didn't work, but DELETE FROM amasty_gdprcookie_cookie WHERE 1; did the trick. I'll update my post with the working solution. Thanks again
    – Terence Patane-Ronan
    Aug 3, 2020 at 16:52

Your Answer

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

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