@yuriy-barvenko Ok, I'm in the same boat, but I think it is most likely the database back-end. Reason being, I migrated our database from the docker instance to a stand alone instance of PostgreSQL and I immediately noticed some performance degradation.

I'm running version 1.55.1 of FusionAuth and PostgreSQL version 14. There are documented performance improvements in both FusionAuth and PostgreSQL. I'll be updating my version of PostgreSQL and will report back.

@maciej-wisniowski Looks like you are getting some traction on the issue. Thanks for taking the time to work through this and submit the issue to make FusionAuth better.

@mohamed-aziz-khayati does this occur simply when you visit the page or when you try to login (submit your username and password)?

@mark-robustelli Thanks for pointing this out! Yes, magic links will work nicely.

@peanutsunless glad this was useful for you!

@mark-robustelli thanks for clarifying!

@dan Yes, it works as temporary solution. Thanks!

Personally cannot help you much since I have not deployed my monorepo on a server to see how FusionAuth behaves 😓 but I think it would be easier for others to assist you and understand it if you could share a reproducible repo or something of that sort.

I have similar issue with MySql 5.7 and create a issue report here : https://github.com/FusionAuth/fusionauth-issues/issues/2658

Apparently it seem there is typing error in Sql query that miss the table name but use the alias only and hence the error.

@elliotdickison Thanks for posting!

I shared this internally.

Regarding your first point, I agree a table would of MAU/$ would be helpful.

Regarding your second point, really appreciate that (and the feature suggestions/bug reports you make!). We discuss features and pricing pretty regularly, and I'll surface this comment next time we do so.

The suggestions you gave are not very atomic. We have many users with spotty network connections, so we're trying to stick here with 1 API call for registrations.

I hear you. I think we already have some open issues about this, but if you'd like to file an issue outlining your preferred workflow, that'd be great.

The key is not being used on the JWT tab.

@brad Hmm. Thanks for the feedback. Seems like it should have worked.

If you feel like it, please log an issue on our GH issues list: https://github.com/FusionAuth/fusionauth-issues/issues/ with as much detail as you would like. Feel free to reference this issue.

Hello,

It's been a while.

Is it something that can be planned in future?

@jacksontrevan - Let me start of by saying I am not very familiar with React applications. However, thinking about typical application flow, What would happen if the user was already logged in? Can't you get the login screen by just directing them to a secured page vs a "landing page"?

@yves

I'd be interested to see if the same issue occurs on the latest version of FusionAuth. There's 4-5 mentions of Elasticsearch in the release notes between 1.34.0 and 1.45.3, but none of them appear to address what you are seeing.

As mentioned above, also searching directly via id for example fails.

Sorry, I missed that. Are you saying when you search using the ids method (described here under the heading Search for Users by Id) it doesn't find these users? Because that search should go directly to the database and not through ES at all.

It's all a bit suboptimal.

Off topic, but please consider adding your voice to this issue which might help with your schema changes.

@yves

I guess I'm struggling to understand how FusionAuth internally saves the user data. Is this unstructured (e.g. JSON) inside the relational database?

You can examine the database schema FusionAuth uses here: https://fusionauth.io/docs/v1/tech/installation-guide/fusionauth-app#advanced-installation

I guess I can't give this more structure, e.g. defining data types, and so on?

The structure for the .data fields is implicit. This means that you can define the schema by creating a value. So if I set user.data.isPremium to true, then ES will understand that user.data.isPremium is of type boolean.

A couple of notes:

if you change the datatype across users, ES will get confused. Here's docs on how to deal with that: https://fusionauth.io/docs/v1/tech/admin-guide/troubleshooting#mapperparsingexception there's an open issue for allowing schema enforcement. Please upvote it or add other feedback using the PATCH method for arrays in the user.data field is a bit fragile. Here's docs on how to choose this method correctly: https://fusionauth.io/docs/v1/tech/apis/#the-patch-http-method

I guess there's also no "direct" access to the user data via an API? At least I didn't find anything.

You can update, patch or remove values from the user.data field using the normal user APIs. Or did I misunderstand your question?