HELP! Database trigger is trigger on new user created without it being true?

Need help APIs
1

Hi all, running into a weird issue I can’t seem to fix. I have a database trigger that sends an email to me (admin) anytime a new user is created.

This is how I’ve set it up:

image

image
image548×982 41.1 KB

I haven’t had any signups in my version-test or live version yet it sends me this email every few minutes! I’ve checked the logs and it looks like it thinks that a user is indeed being created?? In the database this userID doesn’t exist when I search for it, and there’s definitely no users being created.

image
image2646×1102 146 KB

There’s also no backend or recursive workflow changing the user whatsoever…

2

Are you running this workflow without authentication? or as a public api?

When a user visits your bubble app, bubble creates a cashed user … this might be related to this issue

You can make sure that the api should run with authentication and not as a public
If you need to keep it without authentication, you can then narrow down the condition to include a field you fill on sign-up or account creation … like user before change platform is empty and now is not empty

3

Well it’s a database trigger rather than an API workflow, does this still apply?

4

Btw, I don’t think it’s a visit to the site either. At the moment no one is visiting it :slight_smile:

5

Ah sorry I misread a part and thought you’re triggering after the action with a schedule api call.

Then try you can narrow down the condition to user before change platform is empty and after change is not or first name and let me know if it works with you?

6

I did First name and it worked! Thank you!

1 Like
7

Hi, I am hypostasizing based on observations of browser session tokens… I think I can suggest a reason why your DB trigger was doing what it was.

When monitoring session variables to an app without logging in (I.E. just a landing page/home page), it seems (I believe) bubble creates a session variable and a “fake” User and associates the ID with the session variable. This actually makes sense from a coding point of view since any authentication routines now have something to test against rather than having to trap out “no user” every time. I am guessing that this fake user is actually added to the USER table and maybe a hidden record that we the app developer can not see. Which also makes sense, since why would we want to see transient “users” that are not really users.

If this is the case then the DB would get triggered since there is a change to the table. But, if you use a field you control as the trigger-test then the DB trigger would not fire on this change. I have not tested this, but it would explain your observations.

John

1 Like