Fewer requests to Shipping Rate module

[andyjv]

Description (*)

When entering shipping information at checkout, there are observers on three fields that trigger the script that fetches new shipping rates. Those fields are Zip and Country. When any of those fields are changed a new request for rates is made, and it does not take anything else into account.

As the user enters a postal code, Magento will request rates after about 1 second after the last keypress, regardless of all other facts. If the user is slow, this could result in many requests. There are many reasons why a user would be slow: made a mistake and looking for the mistake; reading the postal code from another source; typing on a phone; any combination of the above.

This multiple request situation could occur of a browsers auto-fill enters in information, and the user goes to change it.

Multiple requests can also occur even if the user is quickly entering information; if just one service provider (UPS or FedEx) is experiencing an issue, it can delay the response.

Most critically, if the request takes longer than one second, depending on user actions, there could be several requests pending at once. Those requests are not required to finish in the order they were made. This can result in invalid shipping rates (or no rates at all).

Expected behavior (*)

Magento should be aware of what information is required before a shipping rate request is made. That information should be validated locally before getting sent to the server for further validation, and only when the information is valid, should a shipping rate be requested. There should only be one active request at a time. If a new request is made, the old one should be cancelled or the new request needs to wait for the original to finish.

Benefits

By improving the way Magento requests shipping rates, there are several benefits to both merchants and shoppers:

• Fewer requests means less unnecessary data usage for mobile users.
• A smoother checkout experience, as the user would be exposed to fewer "loading wheels".
• Fewer requests to service providers; If Magento merchants have custom shipping solutions, I doubt they want to be spamming their service provider with bad API requests.
• By validating information before sending it, users will not see inaccurate shipping rates.

Additional information

[magento-engcom-team]

Hi @andyjv. 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.

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

• [ ] yes
• [ ] no

[magento-engcom-team]

Hi @engcom-backlog-pb. 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 Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [x] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description 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 Issue: Confirmed once verification is complete.

• [x] 7. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

@engcom-backlog-pb Thank you for verifying the issue. Based on the provided information internal tickets MAGETWO-95792, MAGETWO-95793 were created

[webkul-ratnesh]

I think only following the flow to restrict one ajax request at a time, will solve this issue. Because as per the concern regarding mobile data usage, the request and response will have total overhead of 700 bytes to 1 Kilo bytes, and that is not a matter of concern. Regarding the concern of validation at browser end, The shipping method estimation is based on the information only:

1. State
2. Postal code
3. Country

The scope of all three field's value is very vast and validations are already made on it.