Accounts and Profile 500 error

Good day! I am having some problem regarding my fresh upgraded openedx. To give you some background of my instance, our openedx is native installed (koa version) and through this discussion’s help from fellow developers, we’ve managed to migrate its data from native to tutor successfully, and now we are currently using the tutor deployment (olive version) in a separate instance.

We haven’t configured anything yet but our openedx seems to be having a problem. In the dropdown image below, the Profile and the Account tab doesn’t seem to be working properly.

Here is what it looks like: (I’m currently using dark mode and have the mfe plugin enabled, please don’t be confused)

The Profile Tab

The Account Tab

The profile tab keeps loading on like forever and the account tab has this error stating “Error: Axios Error (Response): 500[username][Response is HTML]”

Attached below are the traceback errors using tutor local logs --tail=100 -f:

Profile Traceback.txt (66.4 KB)
Account Traceback.txt (67.9 KB)

I hope my fellow developrs can help me.

One quick question. Have you configured your DNS properly as per

For example, if the LMS is on, the CMS should be on

The profile MFE should then be on

The account MFE should then be on

I am not convinced your current configuration for should work.

I also see the following in your logs
lms_1 | account_settings = get_account_settings(: OperationalError(1054, “Unknown column ‘auth_registration.activation_timestamp’ in ‘field list’”)

I see a reference to this field in both the Profile Traceback and Account Traceback you shared.

I know you previously stated in a post that you were moving from Native Koa to Tutor. Did you migrate first to Tutor Koa and then to Tutor Lilac and then to Tutor Maple and then to Tutor Nutmeg and finally to Tutor Olive? It seems to me that you might have skipped some of the Django migrations that normally occur in-between versions.

If you did, something might have gone wrong while upgrading from one release to the other. I am sorry if I cannot tell you where this might have occured.

I would suggest you ask your DBA to look at the openedx database and check the schema for the auth_registration table because activation_timestamp should still be there at least on Nutmeg (I just checked on our production server).

I suspect something went wrong while upgrading from one release to another.

Yes. I configured it correctly. I used an online dns checker to check if it redirects to the correct DNS and it does.

Well, I do recall that through running tutor local quickstart (I’m not quite sure if I remember it correctly that it occured on the process of migrating from lilac to maple), we’ve crashed through a migration error, but we’ve managed to fix it by running migrations using migrate --fake. Does it cause any trouble from there?

I also checked our previous native koa server, and compared it to our current server, upon checking the database, even the koa version’s auth registration table has no “activation_timestamp” column.

Here’s my evidence:

That’s strange. I can confirm it is present on our production Tutor Nutmeg server and in our test Tutor Olive server.

I could go check on an archive of our old Native Koa server, but it would take some time before I get back to you.

One thing I noticed. Your database is still called “edxapp” according to your TUTOR OLIVE SERVER screenshot. It should be called “openedx” if you followed the instructions on how to import the MySQL database from Native to Tutor.

@Engr_James_Lusuegro I can confirm that the “activation_timestamp” column didn’t exist for us in Native Koa. It is definitely something that was added during the migrations from Koa to Nutmeg (and Olive).

mysql> describe auth_registration ;
| Field          | Type        | Null | Key | Default | Extra          |
| id             | int(11)     | NO   | PRI | NULL    | auto_increment |
| user_id        | int(11)     | NO   | UNI | NULL    |                |
| activation_key | varchar(32) | NO   | UNI | NULL    |                |
3 rows in set (0.00 sec)

It seems to have been added in Lilac according to

Thank you for noticing this. But on our case, we also followed the instructions indicated here into restoring migration data which indicates that there are two methods:

a. (Recommended) Edit your MySQL dump file:
i. Add DROP DATABASE openedx; to the SQL file above the CREATE DATABASE line.
ii. Change CREATE DATABASE /*!32312 IF NOT EXISTS*/ edxapp /*!40100 DEFAULT CHARACTER SET utf8 */; to CREATE DATABASE /*!32312 IF NOT EXISTS*/ openedx /*!40100 DEFAULT CHARACTER SET utf8 */;
iii. Change USE edxapp ; to USE openedx ;

b. Set OPENEDX_MYSQL_DATABASE: edxapp in your $(tutor config printroot)/config.yml file. If you are using an external database provider, you should set the following

OPENEDX_MYSQL_PASSWORD: <mysql_password>

we followed b. Setting OPENEDX_MYSQL_DATABASE: edxapp in your $(tutor config printroot)/config.yml file since we’re having difficulties on of how large our database is.

Which keeps me wondering… would it affect the migration though if we followed the second option? If it does, is there a way on how can we perform the first option on a larger database?

Also, this may be it… honestly, the moment we were upgrading from koa to lilac, there seems to be an error from there… I forgot to take a screenshot of it. Our workaround was to fake it’s migrations using migrate --fake but now, I’ve realized it didn’t really fix anything.

We’re planning on starting from scratch from our migrations as you’ve indicated that there is something missing from our migrations. I hope you can still help if I would post the error here about our upgrade from koa to lilac.

Our MySQL database dump was also very large, so we used “split” in order to split the dump file in smaller chunks in order to edit the beginning of the first chunk to add the drop database instruction and replace edxapp by openedx as suggested in the recommended solution a). Of course, it also means concatenating all chunks afterwards in order to recreate the newly modified large MySQL dump file.

Thank you for your consistent replies. We will try to perform the said instructions. If problems occur, I think I would post another topic for that separate question.

One last question though, how can you perform the split and the concatenation process? If it would be quite difficult to explain, can I please just receive a reference for a starting point?

I would suggest you read on the command split and cat.

man split
man cat

Lets say you have a file called big_file.txt that is too big to edit with vi or emacs or any other editor.

Create a directory called split_file at the same level as big_file.txt

mkdir split_file
cd split_file
split ../big_file.txt

After it finishes, it can take a while, edit the first file created. It should be named xaa if I remember correctly.

Afterwards, concatenate all files in this directory to create a new file:
cat * > ../new_big_files.txt

Thank you for your assistance. Hoping for our successful migration! :grin: Will now try this one out.

Hello @sambapete ! We’ve managed to run a new instance for tutor and attempted an upgrade. We performed the recommended migration procedure than the latter. But we’ve ran through some error. I hope you can check this one out.

Upgrade from koa to lilac migration error - Development - Open edX discussions