Hello,

This is not a direct bug, but maybe a safety net for other users to not do the same mistake as we did.

We had a prod environment going down due to fusionauth OOM errors which were cause by a bug on one of our services. There is everything fine with the FusionAuth in general, but the problem was that we filled up the users.data field for each user with too much data due to an error (should only have been a list of some bytes). Therefore, after some months we started to have some occasional OOM errors of FusionAuth, as the 0.5GB RAM were not sufficient anymore to load even a single user (which had a users.data text field of 400MB).

After cleaning that, everything is back to normal.

My proposition might be, to put a (maybe configurable) size limit on the *.data fields to prevent such hard to catch runtime errors.

Feel free to ask back for more info, I just wanted to put this here in case you might wanna consider it

Yeah, that was it... I guess it was already late

@dan Yes I did increase it until 2GB, but then loading a list of 4 users also fails ^^

So I think it is just not a good idea using FA as a database

Will look into the feature request.

Thanks, that was exactly what I was looking for. I just didn't stumble across this part of the docs.

To your question, I guess it is already at the right place. I would maybe just mention it in the create events and link this part of the docs as otherwise (at least in my case where most of the webhooks already work), I did not go back to the general webhook setup docs.

This is something I have already tried ad did not work. At least not with my setup. I have changed my setup and use now two databases instead of two schemas.

@dan Yes I did increase it until 2GB, but then loading a list of 4 users also fails ^^

So I think it is just not a good idea using FA as a database

Will look into the feature request.

Hello,

This is not a direct bug, but maybe a safety net for other users to not do the same mistake as we did.

We had a prod environment going down due to fusionauth OOM errors which were cause by a bug on one of our services. There is everything fine with the FusionAuth in general, but the problem was that we filled up the users.data field for each user with too much data due to an error (should only have been a list of some bytes). Therefore, after some months we started to have some occasional OOM errors of FusionAuth, as the 0.5GB RAM were not sufficient anymore to load even a single user (which had a users.data text field of 400MB).

After cleaning that, everything is back to normal.

My proposition might be, to put a (maybe configurable) size limit on the *.data fields to prevent such hard to catch runtime errors.

Feel free to ask back for more info, I just wanted to put this here in case you might wanna consider it

Sure!

The PUT method is used to replace an existing object completely with the provided information. This means I need to provide the complete informations of the object even when I only want to update one single value. (If I don't, all values which already exist but I do not provide get wiped!)

The PATCH method will merge the provided information into the existing object, meaning I can only give the missing information without having to provide the rest of the values, too.

This is already implemented on the API level of fusionauth, but just not available in the client libraries. This would be very handy, as with the PUT request, I am forced to GET the object first to then be able to change information and send a second PUT request to update it. BUT, when I have the object-id already, I can directly PATCH a single data field and cut the transaction count in half.

You can have a look at the different ways described here.

I hope this is clearer now, otherwise come back to me

PS: I would like to have this on every endpoint which already provides PATCH methods documented in the api docs here. (The functionality is already there, just not accessible by the client libs.)

Hello,

I am using the typescript client library and I was wondering whether the PATCH method is also available somewhere in there, which is documented in the REST API though.

The PUT request, as usually used by update<Resource>() overwrites the complete object and requires to retrieve the object beforehand. The PATCH would allow to just overwrite some values and is very handy. (Currently I use it for example to setup my default tenant while kickstarting)

I have seen in the library that there is a function .withMethod("PUT") here which gets called from any update<Resource>() method and was therefore wondering why no .withMethod("PATCH") for lets say updatePartial<Resource>()? The client libs are autom. generated if I understood this correctly, so it should not be such a big problem, or did I miss something crucial?

Thx for clarification!

Cyrill

Hello,

I can see on this page that a Key Manager only can be created with admin or kickstart.

When I have a look at the kickstart docs, I cannot find how to do that. There are all other api key features explained, but not the keyManager setting.

From the first page I can see in the return data of the api keys, which field must be set to do it, but this is only guessing and might be good to be clarified.

This is something I have already tried ad did not work. At least not with my setup. I have changed my setup and use now two databases instead of two schemas.

Hi, I have been using the local docker setup for fusionauth with a local postgres db until now. Now I wanted to switch to a hosted DB solution, where I do not want to give the root passwords to the fusionauth app, but instead set up the DB schema manually. This worked so far without any problems, but I was wondering whether I could install the DB schema as a non-default schema instead of using the public schema which is provided by the DB at launch?

I was able to set it up and create a user, but the connection url jdbc:postgresql://db:5432/fusionauth and the config files do not provide the possibility to select a specific schema on the DB and default automatically to public.

Such as

CREATE SCHEMA my_fusionauth_schema
    AUTHORIZATION postgres;

ALTER DEFAULT PRIVILEGES IN SCHEMA my_fusionauth_schema
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLES TO fusionauth;

Thank you for your answer ansd clarifications.

Cyrill

Thanks, that was exactly what I was looking for. I just didn't stumble across this part of the docs.

To your question, I guess it is already at the right place. I would maybe just mention it in the create events and link this part of the docs as otherwise (at least in my case where most of the webhooks already work), I did not go back to the general webhook setup docs.

Yeah, that was it... I guess it was already late

Hello, I came a across a strange behaviour, as I was playing with the user.created event. I listen to this with a webhook when a new user is created and then I create a user entry on my side, too. But as I have a default application, I wanted to automatically create a registration for this user. This is not needed when it is a self-signup, but only when the user is created in the fusion auth app.

I understand now that when the webhook fails, the user does not get created, and that is why the user cannot actually exist yet in the database of fusionauth. But the docs are missleading as they state that the event user.created is fired upon a user creation, which indicates the user already exists.
Event: User Created

Did I understand correct or is there something I have missed?