Order History in Olive and Palm

I had never noticed it before earlier this week, but Order History in Olive or Palm seems to be broken.

As you can see from the screenshot, it does not seem to work and the page keeps on trying to load.

I am not a Javascript or React specialist, but the developers console seems to indicate that properties for map are undefined after trying to access ORDER_HISTORY__FETCH_ORDERS.

Looking at the code from Nutmeg where it was still working and the code from Olive and Palm, I can see in frontend-app-ecommerce/src/order-history/service.js at open-release/olive.3 · openedx/frontend-app-ecommerce · GitHub that there are multiple references to COMMERCE_COORDINATOR_BASE_URL as if experimental code had been added to it in order for the developers to test Commerce Coordinator.

I am wondering it this does not have a bizarre side effect for people running Olive or Palm.

Is anyone running ecommerce under Olive or Palm facing the same issue?

@pshiu would you know anything about it?

Thanks for any information or help resolving that issue.

Hi @sambapete!

We looked into it, but on a review of the code couldn’t immediately identify why you might be getting that particular error.

Could you provide please:

  • A screenshot of the line of code that appears in the Sources tab when you click on “service.js:21:43”.

    • This will help us rule out which of the two places in the code this is happening.
  • A HAR file from your Network tab, redacted using a tool like Google’s HAR Analyzer. (More info: see walkthrough)

    • This will tell us what your local ecommerce instance is sending frontend-app-ecommerce.


Hi @pshiu ! Sorry for the late reply, I didn’t see your reply and I was out for most of the evening.

I reinstalled the server with and without our fork, but I always get the same error message on service.js:70:43

Somehow, I think the data variable isn’t initialized correctly.

Running tutor v15.3.5 and olive.3.

I will do the HAR file later on after I read more about it.

I also tried it on a brand new server under tutor v15.3.7. That would normally run olive.4 or olive.3 when using Tutor with the defaults parameters.

I ran into the same issue. I can now at least conclude it isn’t in our fork of Open edX.

I am definitely under the impression that ‘data.results.map’ isn’t initialized properly when we reach line 70.

Is the waffle it refers to on line 30 the waffle flag mentioned in https://github.com/openedx/frontend-app-ecommerce/tree/open-release/palm.1? enable_receipts_via_ecommerce_mfe

It isn’t mentioned for Olive but I did add it to the ecommerce Djando Admin just in case.

I have a hunch that line 40 is true and that line 41 changes CallCC to true and that in the end, it doesn’t know what to do with orderFetchingUrl because I never setup COMMERCE_COORDINATOR_BASE_URL on line 26.

Could I be onto something?

@pshiu And here is the HAR file. I gzipped it before uploading it.

The recording starts when I select “Order History” from the pull down menu in the Account MFE.

apps.cours-virginie.edulib.org_redacted.har.gz (544.3 KB)

Excellent, thank you for the diagnostic information Pierre.

From your HAR file, I see that there is a request to get the user’s order history via https://apps.cours-virginie.edulib.org/api/v2/orders/?username=sambapete&page=1&page_size=20, but the response is empty:

Screenshots of HAR file empty response

The correct response from ecommerce on that endpoint should be, on a user with no orders:

    "count": 0,
    "next": null,
    "previous": null,
    "results": []
Screenshots of edx.org response for user with no orders

I’m not sure why https://apps.cours-virginie.edulib.org is responding with a blank 200 OK, but I suspect your build of frontend-app-ecommerce may be incorrectly reaching out to https://apps.cours-virginie.edulib.org/ when it should be reaching out to something like https://ecommerce.cours-virginie.edulib.org.

Is it possible this is caused by a lack of set of ECOMMERCE_BASE_URL while your frontend-app-ecommerce is building?

See below comparison of:

Screenshot of HAR file JS environmental variables

Screenshot of edx.org JS environmental variables

Reference: openedx Confluence: Micro-frontend MFE Onboarding, § Configuration


I tried setting up ECOMMERCE_BASE_URL and rebuilding my images. Nothing. It is still trying to reach out to Order History | edX

I’ve noticed that it also refers to “ORDER_HISTORY_URL”: “Order History | edX” but the ORDER HISTORY should be at https://ecommerce.cours-virginie.edulib.org/api/v2/orders/?username=sambapete&page=1&page_size=20 in order to reach the API.

I’ll try something else.

P.S. I will set up ECOMMERCE_API_BASE_URL as https://ecommerce.cours-virginie.edulib.org/api/v2/ and let know you know what happens.

Following discussions with @pshiu and after trying a few things, I found a “workaround” that will work for us but that may not work for most people.

I’ve tried setting the following environment variables in a plugin with MFE_CONFIG but none of them would get passed to the frontend-app-ecommerce MFE and therefore it would not display the Order History.


It’s probably because the tutor-mfe and the tutor-ecommerce plugins handle MFE_CONFIG differently. Not being an MFE expert, it’s probably something @arbrandes or @regis should take a look at.

Anyways, in our case we previously needed to fork tutor-ecommerce to use our fork of frontend-app-payment because we wanted the currency to display in CAD and we did not want to display the PayPal button.

In order to fix our Order History problem, we also needed to use our fork of tutor-ecommerce in order to use our fork of frontend-app-ecommerce.

Because we did not find a way to setup the values of the environment variables through various plugins, we had no choice but to set them up in the .env file of frontend-app-ecommerce.

This will work because we use our own forks of tutor-ecommerce and frontend-app-ecommerce, but it will not work for anybody else.

As we are still one of the rare Open edX instances to still use ecommerce as of Nutmeg, Olive and Palm, this workaround works for us, but it will not be working for anybody using a default Open edX installation.

1 Like