Hi there, I am trying to call the sign_up function from the supertokens_python.recipe.emailpassword.asyncio library. When I call

result = await sign_up(sign_up_input.email, sign_up_input.password)

I get the error message

TypeError: sign_up() missing 1 required positional argument: 'tenant_id'

But when I do the call

result = await sign_up(tenant_id="", email=sign_up_input.email, password=sign_up_input.password)

I get the error

TypeError: sign_up() takes 3 positional arguments but 4 were given

Is this a bug? Using version 0.16.0 of the supertokens python sdk

hey @SuperEric this is very strange. How are you importing sign_up?

I am importing sign_up via this line:

from supertokens_python.recipe.emailpassword.asyncio import sign_up, send_email, create_reset_password_link

Looking at the source code it really doesn't make sense why this issue is happening. I ran

st_version = pkg_resources.get_distribution("supertokens-python").version
    print("supertokens version:")
    print(st_version)

And confirmed that I am running 0.16.8 of the supertokens library where this error is happening

Yes. It doesn’t make sense at all. Very very strange.

So I switched from FastAPI to Flask based on an issue I saw in the supertoknes github repo... This did not solve the problem, but it gave me a more specific error message that pointed out to me that I needed to add

tenant_id

to all of my override functions as well as any sdk functions I am calling. I was previously on 0.14 of supertokens python where tenant_id is not necessary, but in 0.16, it is necessary everywhere

Yup. That’s true.

For this library upgrade from 0.14 to 0.16, we also need to upgrade the core service from

supertokens-postgresql:6.0

to

supertokens-postgresql:7.0

. This resolves the error

Caused by: org.postgresql.util.PSQLException: ERROR: null value in column "primary_or_recipe_user_id" of relation "app_id_to_user_id" violates not-null constraint

But in order to apply the schema change to the database, I deleted all the tables and then redeployed the core service docker container tasks, which seeded the DB with the latest schema. Do you know the suggested way for applying schema changes from a core service upgrade to an existing database without deleting the tables?

Yup. We have a migration script in there core changelog

🥳