Some users in Distru have not had their transfers cache updated since 06/28/2022. An example of this is this Asana ticket.
Impersonate user: yaya+1@flavrhouse.com Order ID not syncing: 495908
I tried tried to run a transfer update job in our production env for the license during the date of 06/28/2022 like so while having a bunch of logs in place in lib/distru/metrc/transfer/transfer.ex:
license = Distru.Repo.get!(Distru.License, 235592) |> Distru.Repo.preload(:company);
Distru.Metrc.Transfer.update_transfer_cache(
license,
license.company.metrc_default_user_key,
Timex.shift(Timex.now(), hours: -23),
Timex.now()
)
I found that we failed to update Order ID 495151 that crashed the transfer cache update. It turns out that the order had a line item which did not have a package associated, even though it was already matched to Metrc transfer with metrc_id=3680314.
I then checked the payload from Metrc on that transfer and noticed some oddities:
ReceivedPackageCount=19,ReceivedDeliveryCount=1
ActualArrivalDateTime=null,ReceivedDateTime=2022-06-28T20:50:37+00:00,DeliveryReceivedPackageCount=19
- Every single package in here had
ShipmentPackageState=Accepted
So it seems that the Metrc transfer 3680314 was received on 2022-06-28T20:50:37+00:00, and we tried to update the SO 495151, one of it's line items (id: 5759686) had no packages associated to it, causing our update job to crash.
distru_prod=> SELECT id, quantity, package_id FROM order_items WHERE order_id = 495151;
id | quantity | package_id
---------+--------------+------------
5728749 | 20.000000000 | 2564924
5728750 | 20.000000000 | 2564928
5728751 | 20.000000000 | 2564935
5728752 | 20.000000000 | 2564937
5728753 | 20.000000000 | 2564941
5728754 | 20.000000000 | 2564944
5728755 | 16.000000000 | 2564946
5728756 | 4.000000000 | 2564950
5728757 | 20.000000000 | 2564957
5728758 | 20.000000000 | 2564977
5728759 | 20.000000000 | 2565002
5728760 | 20.000000000 | 2565004
5728761 | 10.000000000 | 2565005
5728762 | 10.000000000 | 2565008
5728763 | 10.000000000 | 2565009
5728764 | 10.000000000 | 2565013
5759686 | 11.000000000 |
5728766 | 40.000000000 | 2565023
5728767 | 40.000000000 | 2565026
UPDATE: The customer said that the specific line item where the package was removed (id: 5759686) from had it's received quantity be 10 instead of 11. However, this still doesn't explain how the package was removed from the line item
UPDATE #2: I checked further and it seems that the package has a transaction history item of being associated with the SO, and it even has a selling stock, but that stock does not have an order_item_id associated, however the stock does have an assembly_output_item_id associated:
-[ RECORD 5 ]-----------+------------------------------
id | 12172477
status | metrc_transferring
quantity | 0.000000000
stock_transfer_item_id |
order_item_id |
assembly_input_item_id |
assembly_output_item_id | 2074597
batch_id | 554231
creator_id |
user_id |
location_id | 249307
inserted_at | 2022-06-28 20:46:58.933411+00
updated_at | 2022-06-28 20:47:47.414495+00
return_item_id |
package_id | 2565018
product_id | 496542
package_quantity | 0.0000
intake_order_item_id |
plant_id |
teardown_input_id |
teardown_output_id |
harvest_id |
breakdown_input_id |
breakdown_output_id |
The assembly associated to the output item is Assembly ID: 2053051 which is a inline_repackage assembly.
UPDATE #3: In the meantime to fix the issue for the customer, I re-attached the selling stock to the order item, and reattached the package to the order item like so:
UPDATE stocks SET order_item_id = 5759686 WHERE id = 12172533;
UPDATE order_items SET package_id = 2565018 WHERE id = 5759686;
UPDATE #4: Apparently the transactions associated with the package also show 2 transactions of this package being added to the SO, but zero transactions of it being removed from the SO, and also neither transactions have the order_item_id filled