REV-2575: update order status page to go through commerce-coordinator

[dianekaplan]

Description: Update the order history page to be able to call the new commerce-coordinator endpoint from this PR.

• Continue calling ecommerce for order info, which has been updated to include the value for the new enable_hoist_order_history flag (if the user has orders).
• if that flag is included in the results and it's set to true, do a second call to the new commerce-coordinator endpoint, and have the page display orders based on that result instead
• After we've confirmed tin production that we can successfully retrieve the order data via the commerce-coordinator endpoint, we'll have a follow on PR to the special logic and uncomment the suggested/commented beneath it to simply call the commerce-coordinator endpoint for order history (and no longer call that ecommerce endpoint directly)
• Note: I haven't added any new tests. Currently this page is tested using mock order data. That order data will be the same when returned via commerce-coordinator, and while we're adding more complicated logic in the interim (to call one endpoint then another), after we've verified this working in prod we can return to the identical/simpler logic currently in use. The temporary double-calling logic has more complexity/length than the regular call we do today and the one we'll make to commerce-coordianator after we use this test code, flagged by the codecov build check there our test percentage is less. (But when we return to the original code that just hits the other endpoint, we'll be back to the same).

JIRA: Link to JIRA ticket

Testing notes:

• in your local ecommerce admin, add waffle flag 'enable_hoist_order_history' with value Yes
• start up locally: devstack with ecommerce, commerce-coordinator, and frontend-app-ecommerce
• log in to localhost with a user who has orders
• go to the order history page: http://localhost:1996/orders
  Result: the order history page loads the orders info (in double the time now that we're temporarily performing two sequential calls. This is around 48 seconds locally, but the prod page is under a second today so I don't expect that temporary doubling will be a problem. Will confirm with the team). Inspect in the browser's console tab to see the responses from the ecommerce and the commerce-coordianator's endpoints

[codecov]

Codecov Report

Merging #181 (9f288c1) into master (9635012) will decrease coverage by 5.27%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #181      +/-   ##
==========================================
- Coverage   54.05%   48.78%   -5.28%     
==========================================
  Files          15       15              
  Lines         148      164      +16     
  Branches       25       28       +3     
==========================================
  Hits           80       80              
- Misses         65       79      +14     
- Partials        3        5       +2     

Impacted Files	Coverage Δ
src/order-history/service.js	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9635012...9f288c1. Read the comment docs.

[dianekaplan]

This big 'TEMPORARY CODE for rollout testing/confirmation' block is for use to sanity check using the commerce-coordinator endpoint for order history. Therefore I've included some debugging statements so our production test can be explicit about where the data came from. Is there a better way to do this, or are these statements okay for this temporary case?

[julianajlk]

As long as we're not logging any PII, and assuming we'll be logged-in in our accounts anyways (so the information will be ours), we should be good!

I would change DKTEMP to something theseus/commerce-coordinator related though to be more specific, in case the temporary code is not as temporary as we imagined?

[dianekaplan]

Good call- updated the logging prefix to 'REV-2577 LOG' (that'll be the testing ticket). There is PII in this data (name and address), but console.log should only make this appear in the user's own browser, as opposed to something like Splunk which shows server-side logging that's put there with a different/specific Logger.

[julianajlk]

Here data is replaced with the newData from commerce-coordinator, but then both data and newData are logged - aren't they the same thing at this point in the code?

[dianekaplan]

Yes these will get the same json results, the only difference being that one will go through commerce-coordinator. I do the replacement because even though these results aren't actually different, when the waffle flag is enabled we want the order history page to show the data coming back from commerce-coordinator. (As opposed to just calling the commerce-coordinator in the background but not actually showing the data we get from it).

[julianajlk]

This is great Diane! Good to see how the waffle flag is being used as expected. Just some minor comments but overall makes sense (considering it was agreed that for now we will call ecommerce first to get the flag value :) )