'shipping_method' column in sales_order and quote_address table size limit inconsistent/too small

[reztierk]

The size of the column 'shipping_method' in the sales_order and quote_address tables are too small and inconsistent. This may cause an issue with a custom carriers methods as some may have larger method codes ( ie Purolator has a method with a code of 'PurolatorExpressInternationalEnvelope10:30AM' )which will become truncated upon saving and make the order return errors when creating a shipment. It is also noteworthy that the column length on the quote_address table is 40 while on the sales_order table it is 32. This will also cause issues with core Fedex module as some of the methods supported already exceed the lengths available (ie 'EUROPE_FIRST_INTERNATIONAL_PRIORITY'), prior to adding the carrier code which is appended to the method code when saving (ie the intended field value would be 'fedex_EUROPE_FIRST_INTERNATIONAL_PRIORITY').

Preconditions

1. Magento version(s) 2.1, 2.0

Steps to reproduce

1. Place an order using a shipping method where the carrier code combined with the method code length exceeds 32 characters.
2. Create shipment for order with packing label.

Expected result

1. Shipment is created successfully

Actual result

1. Shipment creation fails due to mismatch of Method Code.

My recommendation would be to use the same value for the field length that was used in Magento 1 of 255.

[SerhiyShkolyarenko]

@reztierk thank you for reporting the issue. We created internal ticket MAGETWO-58722.

[wsagen]

This is a really fundamental bug and is preventing checkout for a lot of carriers. Please can advise when a fix will be available?

[birchestx]

This is affecting us on ShipperHQ. There are a large number of carriers that exceed this, we need it to be in region of 80 combined to be non-impacting. Aus Post is another example e.g. AUSPOST_INT_LETTER_AIR_OWN_PACKAGING_MEDIUM. We also add other information on the end of the method code to help the post-order labelling systems (e.g. zone, pick desk, etc), so we need this higher else they all stop working. We have working M1 clients migrating to M2 and finding system no longer works.

[SerhiyShkolyarenko]

@wsagen @wsakaren thank you for taking part! We don't have fixing time estimate, but MAGETWO-58722 was promoted in priority today.

[birchestx]

It actually needs to be 120 if possible combined btw.

[ddeppner]

FYI, this bug is currently blocking our ability to launch our new M2 site. Any time estimate or update on a solution?

[SerhiyShkolyarenko]

@ddeppner i can state that this issue is marked as high priority, but I don't have any estimates on fixing.

[romainruaud]

@SerhiyShkolyarenko I see the attached commit, estimating this one will be part of Magento 2.2.x branches.

Any chances to have it fallbacked quickly to 2.1.x ?

Best regards

[magento-engcom-team]

@reztierk, thank you for your report.
The issue is already fixed in 2.2.0

[romainruaud]

Dear @magento-engcom-team

Imho this fix is not sufficient. Since it's put only in an UpgradeSchema, it is not triggered when installing from scratch.