Magento2: Magento 2.2.6 coupon codes don't work anymore

[Cristiano81]

Preconditions

1. Magento 2.2.6
2. Cart price rule based on coupon code

Steps to reproduce

1. Create a cart price rule with specific coupon with date from 2018 to 2088
2. Try add the coupon to the cart

Expected result

1. The coupon has been successfull applied to the cart

Actual result

1. Every coupon code result invalid

[magento-engcom-team]

Hi @Cristiano81. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento-engcom-team give me $VERSION instance

where $VERSION is version tags (starting from 2.2.0+) or develop branches (for example: 2.3-develop).
For more details, please, review the Magento Contributor Assistant documentation.

@Cristiano81 do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [ ] yes
• [ ] no

[Cristiano81]

In 2.2.5 the coupon code work

[Cristiano81]

@magento-engcom-team give me 2.2.6 instance

[magento-engcom-team]

Hi @Cristiano81. Thank you for your request. I'm working on Magento 2.2.6 instance for you

[magento-engcom-team]

Hi @Cristiano81, here is your Magento instance.
Admin access: https://i-18183-2-2-6.engcom.dev.magento.com/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[Cristiano81]

yes i can reproduce the issue on vanilla magento

[Cristiano81]

This maybe be usefull, when i try to apply the coupon code, i received this error on chrome console:
jquery.js:10254 PUT https://i-18183-2-2-6.engcom.dev.magento.com/rest/default/V1/guest-carts/BWM5XQCXhnzdxK9njKSP2cL611NFTmcG/coupons/TEST2018 404 (Not Found)
send @ jquery.js:10254
ajax @ jquery.js:9738
put @ storage.js:62
(anonymous) @ set-coupon-code.js:33
apply @ discount.js:41
(anonymous) @ knockout.js:3863
dispatch @ jquery.js:5226
elemData.handle @ jquery.js:4878

[kunj1988]

@Cristiano81, I have tried with vanilla Magento 2.2.6 and it is working for me, Please provide more details.

[Cristiano81]

@magento-engcom-team give me 2.2.6 instance

[magento-engcom-team]

Hi @Cristiano81. Thank you for your request. I'm working on Magento 2.2.6 instance for you

[magento-engcom-team]

Hi @Cristiano81, here is your Magento instance.
Admin access: https://i-18183-2-2-6.engcom.dev.magento.com/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[Cristiano81]

@kunj1988 thank you,
i just created a test product with price 100$

after that i created a new coupon with this attribute:

after i add the test product in cart and try to apply the coupon discount, this is the result:

maybe you can tell me your coupon configuration if it works

[hostep]

@Cristiano81 : the coupon codes in your screenshot don't match: TEST20118 vs TEST2018, please make sure they are the same ;)

[Cristiano81]

ops you are right :P but even if they are the same it doesn't work,
please try on the active vanilla magento

[hostep]

Ok, I was able to reproduce, and also found out why.

It has to do with the "to date". In your example, you put it in the year 2088.
When I first tested, I just used 2018 and it worked perfectly fine.

After some playing around, it looks like the limit is 20 years, the year 2037 works, but the year 2038 no longer works.

So this is pretty strange.
You say it worked before on Magento 2.2.5? Also with the year 2088?
If yes: then you've found a new bug, but the fix is pretty easy. But I still consider it a bug if it worked in Magento 2.2.5, because this is kind of unexpected.

[hostep]

Hmm, just tested on Magento 2.2.5, it has the exact same problem, so it's not a new bug in 2.2.6. But it's certainly a problem.

[Cristiano81]

Thank you for your support!
I can tell y the same, in 2.2.5 it didn't work with 2088, BUT it worked with blank "to date" , it does not in 2.2.6 .
I'm going to set an early "to date" thank y again

[hostep]

Hmm, I can not confirm the problem with the blank "to date".
See the test instance, I've added a new coupon with code TEST2020 with a blank "to date". And it works, maybe double check if I've missed something?

[kunj1988]

@Cristiano81, yes, I got the same error while adding Date with 09/30/2088 in To field otherwise working fine. It works with max 20 years difference between From and To field.

[magento-engcom-team]

Hi @engcom-backlog-nazar. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [x] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label G1 Passed will be added to the issue automatically. Please, edit issue description if needed, until label G1 Passed appears.

• [x] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add G2 Passed label to the issue by yourself.

• [x] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [x] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [x] 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [x] 6. Add label acknowledged once verification is complete.

• [x] 7. Make sure that automatic system confirms that report is acknowledged.

[ghost]

Hi @hostep so this is bug ? or we can just leave field empty?

[kunj1988]

In my case, While we add To date more than 20 years Magento adding 0000-00-00 00:00:00 value in expiration_date field.

[hostep]

@engcom-backlog-nazar: the fact that the 20 year problem exist is a bug, but it seems to have already existed since Magento 2.2.0 at least (haven't tested further back).

I'm still curious about the exact problem of @Cristiano81 where it worked on 2.2.5 but no longer on 2.2.6, that part hasn't been discovered yet I believe.

[Cristiano81]

@hostep the fact is very curious.
I opened this issue because we had a Magento 2.2.2 with a coupon with these settings:

After upgrade from 2.2.2 to 2.2.5 and after to 2.2.6 this coupon stopped work.
But on our test enviroment where there is the 2.2.5 version of Magento the same coupon works perfectly.
On saturday after some try with the date it starts work also on 2.2.6 ...

[magento-engcom-team]

@engcom-backlog-nazar Thank you for verifying the issue. Based on the provided information internal tickets MAGETWO-95197, MAGETWO-95198 were created

[ghost]

@Cristiano81 maybe edit steps to reproduce, add the step of specific date

[kunj1988]

@hostep, I got the same issue with Magento 2.2.5, I think the issue with MySQL database. It doesn't allow to add date more than 20 years.

[BezV8]

20 years from now is the end of Unix time for 32-bit fields, so that is likely the cause of the problem. Magento would have to move to using 64-bit date fields?

[ghost]

Hi @hostep Hi @BezV8 It looks like this is Mysql bug. -> https://bugs.mysql.com/bug.php?id=12654

[hostep]

@BezV8 & @engcom-backlog-nazar: nice find!

Since that bug was reported in 2005 and hasn't been fixed in 2018, I don't think we should wait on that, maybe Magento (or somebody else) can find a workaround for this?

[kaalar]

@magento-engcom-team give me 2.2.6 instance

[magento-engcom-team]

Hi @kaalar. Thank you for your request. I'm working on Magento 2.2.6 instance for you

[magento-engcom-team]

Hi @kaalar, here is your Magento instance.
Admin access: https://i-18183-2-2-6.engcom.dev.magento.com/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[saphaljha]

Hello @kaalar , Are you working on this issue? Else I'll review and take this issue, Please advise.

[kaalar]

Hello Saphal i working, but i dont to replicate in my local.

El sáb., 13 oct. 2018 15:23, Saphal Jha [e-mail] escribió:

Hello @kaalar https://github.com/kaalar , Are you working on this
issue? Else I'll review and take this issue, Please advise.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/18183#issuecomment-429541525,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AP4IYbb9GCGt46cqMw82_YmYrjQ2f9v8ks5ukelpgaJpZM4W0atv
.

[ravi-chandra3197]

Hello @Cristiano81
I have a re-produce issue in my local

• Create a cart price rule with the specific coupon with a date from 2018 to 2088

After I have checked in database "salesrule_coupon" table and I have found expiration_date is 0000-00-00 00:00:00 because MySQL does not allow date greater or equal then 2038, if we have entered 2037 it's valid but 2038 invalidate, so it's actually a MySQL error. Magento passes correct data (to date) to backend but when data insert into MySQL table it's changing to 0000-00-00 00:00:00 if the year is greater or equal then 2038.

Mysql issue:: WL#1872: Add support for dates from 2038 till 2116 as values of TIMESTAMP type
https://dev.mysql.com/worklog/task/?id=1872

salesrule_coupon table in database

mysql allow if date lessthen 2038. like I have enter 2037 it's valid

mysql not allow if date greater then 2038. like I have use 2038 it's invalid

[magento-engcom-team]

Hi @Shubham-Webkul. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if your want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[Shubham0492]

SQUASHTOBERFEST

[Shubham0492]

@magento-engcom-team give me 2.2-develop instance

[magento-engcom-team]

Hi @Shubham-Webkul. Thank you for your request. I'm working on Magento 2.2-develop instance for you

[magento-engcom-team]

Hi @Shubham-Webkul, here is your Magento instance.
Admin access: http://ec2-34-228-235-121.compute-1.amazonaws.com/i-18183-2-2-develop//admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[Shubham0492]

I am able to reproduce this error in vanila magento.

[konarshankar07]

As expiration_date is a TIMESTAMP so it will have range from '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999'. So it won't save for the 2088 year but if you still want to save so we need to change the column from TIMESTAMP to DATETIME. Hope this will help you.

[giacmir]

Today I encountered this same issue in a 2.1.9 instance.

[vdBrandtMedia]

I have encountered the same issue on 2.2.5, checked the date_to value in the salesrule table but it gives a correct value of 2019-11-26

[magento-engcom-team]

Hi @shikhamis11. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[scottsb]

I agree with @konarshankar07 that the best/correct solution here is to change the expiration column type to a DATETIME instead of TIMESTAMP.

[magento-engcom-team]

Hi @henryktews. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[thomas-avada]

My client encountered this issue for one time. As far as I can tell, it is because the server configuration does not allow PUT, PATCH and DELETE request. You should contact your server guy on this and try my approach to enable all of the above request verbs.

[this-adarsh]

I am working on this at #dmcdindia19

[magento-engcom-team]

@this-adarsh thank you for joining. Please accept team invitation here and self-assign the issue.

[m2-assistant[bot]]

Hi @this-adarsh. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[this-adarsh]

@magento-engcom-team give me 2.3-develop instance

[magento-engcom-team]

Hi @this-adarsh. Thank you for your request. I'm working on Magento 2.3-develop instance for you

[magento-engcom-team]

Hi @this-adarsh, here is your Magento instance.
Admin access: https://i-18183-2-3-develop.instances.magento-community.engineering/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[magento-engcom-team]

Hi @Cristiano81. Thank you for your report.
The issue has been fixed in magento/magento2#22718 by @this-adarsh in 2.3-develop branch
Related commit(s):

• e965f0ca8676b6e71e155843da8ebef1c65ae7da

The fix will be available with the upcoming 2.3.3 release.

[ashvinimarwal]

The issue still exists in Magento 2.3.2.tried to fix it using by change timestamp to datetime in db_schema.xml file

<column xsi:type="timestamp" name="expiration_date" on_update="false" nullable="true"
                comment="Expiration Date"/>
        <column xsi:type="smallint" name="is_primary" padding="5" unsigned="true" nullable="true" identity="false"
                comment="Is Primary"/>
        <column xsi:type="timestamp" name="created_at" on_update="false" nullable="true"
                comment="Coupon Code Creation Date"/>

But still not fixed.