Hello all,
I am stuck with the following:
**Login workflow correctly blocks a failed login, but also blocks a successful one — “Current User is logged in” reads “no” right after “Log the user in” runs**
**1. Application context**
Single popup element (`Popup-Auth`) reused for both Sign Up and Log In, controlled by a custom state (`mode`: `Signup` / `Login`). The popup’s Submit button triggers one workflow with four steps:
- Sign the user up — *Only when: Popup-Auth’s mode is Signup*
- Log the user in (email/password from the popup’s inputs, “Stay logged in” = true) — *Only when: Popup-Auth’s mode is Login*
- Add a pause before next action (1000 ms)
- Hide Popup-Auth — *Only when: Current User is logged in*
There’s also a separate, built-in “X has an error running a workflow” event attached to the same Submit element, with one action that shows an error text element.
**2. Expected behaviour**
- Wrong credentials: popup stays open, error becomes visible.
- Correct credentials: popup closes, page reflects a logged-in state.
**3. Actual behaviour**
- Wrong credentials: popup stays open. Behaves as expected.
- Correct, valid credentials: popup does **not** close. No error appears. The page continues to show a logged-out state. This happens consistently, including in a clean Incognito window using plain Preview (no debug_mode, no debugger), with credentials pasted in (not typed), so it isn’t an artifact of the editor’s debugger or of mistyped input.
**4. Verified facts**
- Using the debugger’s step-by-step mode and Evaluator panel, immediately after Step 2 (“Log the user in”) finishes running with correct credentials, `Current User`'s fields (`email`, `display_name`, etc.) all read empty, and `Current User is logged in` evaluates to `no`.
- Temporarily removing the condition on Step 4 entirely: the workflow then runs all four steps unconditionally regardless of outcome. With wrong credentials, the popup still closed even though the user was not logged in — confirming Bubble does **not** automatically halt a workflow when an earlier action like “Log the user in” fails; later, unconditional steps still execute.
- Adding a 1000 ms “Add a pause before next action” step before checking the condition did not change the outcome — same “no” result, same blank fields, with correct credentials. (We’re aware this particular action only delays on-screen/front-end behavior and doesn’t block backend actions, so we didn’t treat this alone as a real test of timing.)
- To properly test timing, we added a separate Custom Event containing the same condition/check, triggered via “Schedule a custom event” 3 seconds after the original workflow runs — a genuine delay mechanism, independent of the “pause” action above. With correct credentials, after waiting roughly 9 seconds undisturbed (3x the scheduled delay), the popup still had not closed and the page still showed a logged-out state.
- During this same correct-credentials run, the built-in “Submit has an error running a workflow” event does not fire.
- Attempting to reference “Result of step” for the “Log the user in” action in a condition returns “No results found” — this property doesn’t appear to be exposed for this action.
- The bug reproduces identically outside the editor entirely: clean Incognito window, plain Preview URL, no debug_mode, credentials pasted from a verified-correct source. Same result — popup stays open, page shows logged-out state.
**5. What has already been ruled out**
- Editor/debugger artifacts (stale cookies between sessions, manual step-timing, Inspect-mode interference) — ruled out by the clean Incognito/Preview reproduction.
- Mistyped or corrupted credentials — ruled out by using pasted, visually verified text.
- Bubble automatically stopping the workflow when “Log the user in” fails — ruled out; subsequent unconditional steps still ran in testing.
- A short, fixed timing delay being the explanation — tested with a genuine Bubble delay mechanism (a custom event scheduled 3 seconds later, not the “pause” action), waiting roughly 9 seconds undisturbed; the outcome was unchanged.
**6. Remaining questions**
- Is “Log the user in” actually completing successfully with these credentials, by any signal other than the absence of a thrown workflow error?
- Could a Privacy Rule on the User data type cause `Current User`'s own fields — and possibly `is logged in` itself — to read as empty/false within the same workflow run that performs the login, even if the underlying login is genuinely valid?
- Is there a documented Bubble mechanism, other than a fixed delay, under which `Current User is logged in` would never resolve to “yes” after a particular “Log the user in” call — rather than just resolving late?
- Could overlapping or duplicate elements/workflows elsewhere on the page (e.g., a second, similarly named button workflow) be interfering with which inputs or workflows actually engage at runtime?
**7. Question for the community**
Based on these verified facts, what Bubble mechanism are we most likely overlooking? We’re not looking for a workflow redesign — we’d like to know which specific Bubble behavior (privacy rule evaluation order, session/cookie timing relative to login, a known platform quirk, or something else) we should verify next.
