Bug? Can't store correct access_code immediately after creation

I want a user to be able to create data that can be viewed by anyone to whom he/she gives the access_code. Therefore, on signup workflow (using standard Bubble Signup form), I create an access_code for the new user (using the Calculate RandomString function) and store it in the access_code field of the User table. (I added the access_code field to the User table.)

I have a separate table for the (semi-public) data. Therefore, in a second action for the SignUp event, I (try to) store in the access_code field of the data table the newly created access_code (which should now be the “current user’s access_code” created in the preceding action). I do this by storing the “current user’s access_code” in the access_code field of the data table.

BUT, Bubble stores two different access codes in the two tables (viz., the User table and the data table). I only call the “Calculate RandomString” function one time (in the first of the two work flow actions), so I cannot understand how two different codes are being generated. I modify the User table with “access_code = Calculate RandomString” in the first action, and I (try to) modify the data table with “access_code = Current User’s access_code” in the second action. That does not work and I get two different codes in the two tables.

The only way I was able to prevent this was to wait until I navigated off of the page before executing the second action. Then on the page load event of the next page, I stored the current user’s access_code in the data_table. That works.

This is just plain weird and I suspect that it is a bug.

Its really weird and I’ve had the same issue when generating SMS verification codes. If I store the code on the user and then send the generated code (stored on the user) to an SMS provider, it sends a different code.

1 Like

I use the random string to create transactions IDs.

What I do is store the random string in a DB table with name transaction_id and then access that using current user’s transaction_id last item.
It works for me.

1 Like

I’m experiencing the same thing. I tried to get around by generating the random string in a workflow and store it in a state (two strings are generated), and then trigger a custom event copying the content from the first state to a second. It did not work.

Workflow 1
Set state STRING TEMP generate random string (two strings are generated)
Trigger Custom workflow

Custom workflow
Set state STRING, value from STRING TEMP (a third string is generated)
Email string to user (the third string is mailed)

I prefer to not use the database for this, so I’ll keep the page on ice until we know if is indeed a bug or not. Thanks for the workaround anyway @dmurthy.

Just chiming in here: I’ve also experienced having two different random strings generated after calling Calculate RandomString once. The random codes that were sent to my users were different than what was being stored.

I ended up just using Blockspring.

What I think is happening is that the random number is being generated on both the client and the server, with different results.

@josh, could you please explain what is happening, and why some workarounds are effective and others aren’t?

@mishav can you create a simple case that shows the random numbers aren’t the same? It shouldn’t be the case but there may be a bug there.

Hi @emmanuel,

Here is an example, showing @1984labrat’s problem:

(Links removed)

Screen capture:

This is fixed

2 Likes