Up until a couple of days ago (actually, before I upgraded to v6), whenever I assigned the current anonymous user to a field, the condition user_field is empty used to return “yes”.
Now, it does not. I see that now, when you assign the current anonymous user to a field, it actually assigns the temporary user that is created. So now I have to check whether user_field's email is empty.
Has anybody noticed this too? Is it v6?
This broke a few of my conditionals, so I wanted to warn you guys.
Hi there. My app was built on top of Airdev’s Canvas template and I am having some very bizarre behavior around my signup process that I haven’t been able to diagnose. Some user identities seem to be simply disappearing during onboarding, while others are just fine. The former group receive email verification and then, when they go to verify, the user does not exist. When I look in my logs, I see that the user entry was created but can now find no proof that it ever existed. Wondering if this issue might be related. @stephanie, @vlad what do you think? This has really thrown a wrench in my launch. None of these issues showed up during testing, and I’m at a loss for what’s going on. No major modifications to sign up process on our end. Please help
Unfortunately I was not able to replicate this bug using the Canvas starter template. Would you be able to provide a short video of the bug you are seeing? Can you also DM me your app name so I can take a look at the issue? Thank you!
Hi there! Thank you so much for the response. It turns out (predictably) that the problem was with me. I had updated my password policy without updating the conditionals on the first “continue” button during sign up. That left the door open for folks to complete sign-up even if their password did not meet the policy.
What I did not realize during set-up (but now do) is that Bubble will allow this to happen and assign a “temporary” user record. The problem is this record will not show up in user searches (apparently) and will thus break the logic in subsequent workflow steps, so that the user signing up thinks everything is fine and dandy, but will never receive a verification email.
It’s actually an insidious problem and difficult to diagnose. Since those whose passwords meet the policy will be unaffected, you’ll have some sign-ups flowing smoothly, while others are disrupted. I had to do a very close read of my server logs to isolate where the breakdown was.
I would strongly suggest this be highlighted in the Canvas manual, so that new Bubblers aren’t tripped up by it. I should add that Canvas is AMAZING, and I am indebted to Airdev for making it freely available to the community. For any others who stumble onto this thread in the future, I’m also a premium subscriber and after having been one for several months, believe your product has probably the strongest value proposition of anything I’ve paid for — like ever.
Hey, thank you for reporting this and asking for our assistance here. It seems that our documentation needs updated - the Continue button on the signup/login has some conditions that aren’t mentioned in the Canvas Manual.
This is what you found that was causing the issue, is that right?
Thank you so much, Anderson! Yes, indeed. Those are the conditionals to which I was referring. That said, I just got some feedback from a user who is still encountering the same issue, which makes me worry this might not have been the root of the problem, though it clearly was something I needed to address.
Do you have any idea what else might be at issue here? The user in question went through sign-up the first time — no issues with the password or workflows as previously discussed — but the user email address is just dropped from the workflow when it goes to schedule the verification email. He sent me an image of the screen with “unverified” where the email should be.
The strange thing is that when he re-enters his email on the verify screen, it works just fine.
Stranger yet, this behavior only effects a fraction of users, even though I can detect no obvious pattern. It seems to be just dropping users emails at random, so that I have no way of knowing whether verification emails are actually going out. This is obviously a very big problem and terrible UX, but I’m at a loss for the reason.
I would be beyond grateful if you could help me suss out the issue.
I’ve done a deep dive into my server logs and can see where the email is being entered correctly and then not being passed through the workflow. I’ve gone back and examined my workflows, but, again, am at a loss to diagnose what is going wrong or why it’s only affecting a portion of users.
Sorry for the quick-fire replies, but I wanted to ask one other question before signing off for the night. It’s an ignorant one, so I apologize in advance.
The user I referenced is one who had initially reported this bug to me over the weekend. That said, he’s visited the site before, and I wondered if this could be a simple issue of him not having cleared his cache?
I wouldn’t think so, since I can see where the workflows are breaking down in the server logs. However, I’m not a coder and possess a fairly limited understanding of the mechanics of these things. Just wanted you to have the additional context.
Hey TS, if the user is logged in to the app I don’t think that the cache will make a difference. If they’re logged out of the app in the browser tab they’re trying to use to verify the user, that might be the issue - ask them to reset their password and see if they can access the app.
It’s not clear to me what’s happening here, either. Usually it either works or doesn’t work in my experience (e.g. privacy rules are too strong and data can’t be found for all users, or the SendGrid API is not set up correctly).
So is the user appearing in the Bubble DB? Is their email address assigned there?
The verification logic relies entirely on custom Bubble workflows, rather than built-in Bubble verification logic. If the User’s “Date signup completed” date field is not empty, then Canvas app logic considers the User to be verified. You should also search the database for a “Email verification request” object which has the user’s email. See below that this is the field that appears to be empty to the user on the page they’re accessing.
Hi there! Thanks so much for circling back, and sorry for the delayed response. I’m afraid not. I’ve filed an official bug report with Bubble and received an initial response Friday but no resolution as of yet.
I’m curious, have you had any similar complaints come through recently? So far, Bubble is telling me they can’t reproduce the problems outlined above and that it’s likely an issue with the workflows themselves. However, I’ve examined them again and again, and can find no issue. More to the point, the failures seems to occur completely at random, which seems to me the strongest evidence that this is a bug with the platform, rather than a failure of logic. With all the reports of random logic failures and elements deleting themselves in the editor that I’ve been seeing on the forum, I’m growing concerned.
I thought some additional context might be helpful. You can see a real-world example of the first bug (users being randomly deleted) in the first batch of screenshots. The second failure (verification emails failing) seems to occur in the final step of that workflow, as depicted in the second screenshot. Again, the email is not being passed, though I can see in the logs where it was saved properly.
Thanks for the additional context. We haven’t received any reports of similar bugs coming up, and since we use the template for all of our own apps and all the apps we build for clients.
Would you want us to investigate the bug directly in your app’s editor? If so, please DM me with the app id or a link to the Bubble editor and I can enter with our dev Bubble account to try and reproduce the error.
Changing the workflows related to the signup or the verification flow could cause this to happen (not sure exactly how).
Other possibilities include running the “change the email for another user” action, or the “update the user’s credentials” action to change the user’s email (which certainly cause this bug to appear). If you check whether a user exists with the unique ID that was used to run those workflows in your server logs, they should still exist if this were the case. Likewise, if a user were deleted using the Bubble “Delete a thing” or “Delete a list of things” actions, that should be easily identifiable by searching your app for these actions.
Did the email verification not send? I’m not sure what you mean by Email Verification Failure.
Hi again. Thank you so much for your assistance. I’d be delighted to have another set of eyes on this, actually. Very kind to offer. DM’ing that link now.
Regarding the reference to “email verification failure,” yes. As you might recall, we’re seeing two separate classes of buggy behavior during signup. In the first, user accounts are being deleted — seemingly at random — after the verification step. In the second, email addresses are not being passed to the email verification workflow, though the user accounts remain viable and have email addresses attached. For this reason, the Sendgrid API request is sent with a blank “To” field and, thus, fails.
Both behaviors seem to occur at random and only affect a portion of users.
I’m not certain I understand this bit. Would you mind explaining what you mean?
Other possibilities include running the “change the email for another user” action, or the “update the user’s credentials” action to change the user’s email (which certainly cause this bug to appear). If you check whether a user exists with the unique ID that was used to run those workflows in your server logs, they should still exist if this were the case. Likewise, if a user were deleted using the Bubble “Delete a thing” or “Delete a list of things” actions, that should be easily identifiable by searching your app for these actions.
The last bit is what I’d do if I saw this in an app I’m building. You can use the Bubble search tool to make sure that there’s no workflow action that modifies users’ emails or deletes user accounts.
In the template, for example, the user can modify their email on the account page, but the “update the user’s credentials” action shouldn’t be used elsewhere (if I remember correctly).
Thanks for sending that over. It looks like there might be a bug in the verify page of our template, which in some edge cases would result in this happening.
I’ll test this today and keep you updated in case I find anything useful.
Thanks for your patience and helping debug this.
Chris
An Email Verification should have the same email as the User object - it’s created using “current user’s email” as a data source. If somehow an Email Verification is created with an empty email address, this still would not clear the user’s email - I just tested this by deleting the email address from the Email Verification object to see if it would cause a bug, but it ends up just not changing the user’s email in this step.
For now, I’ve deleted the last step in this workflow on the Verify page, which deletes the email verification object. If you decide to push this change live, if this bug happens again you should check for the email verification object for the user you’re looking for, and if there is no object, something went wrong when creating that object.
There’s nothing in your app that I can see which looks like it’d cause this bug, but we also haven’t received other reports of this bug from the hundreds of apps that also use this flow.
Let me know if any of the above is confusing. Thanks again for the patience and hope this doesn’t happen again. If you search in your DB for the user with the unique ID found in your screenshots, that also might be helpful. I can’t search for it since the dev@airdev.co account doesn’t have access to live data in your app, so you’ll need to check this one out.
