Bug: unexpected behavior with None by sign_up_post

[igoose1]

If emailpassword receipe's override doesn't return a Response instance in sign_up_post, supertokens-python responds with an unexpected error which is hard to debug.

In our case we needed to override sign_up_post in emailpassword receipt. By a developer's mistake, new sign_up_post wasn't returning anything when original_sign_up_post was an instance of emailpassword.interfaces.SignUpPostOkResult. Surprisingly, supertokens processed that without any warnings and errors. It responded with a FIELD_ERROR.

{"status":"FIELD_ERROR","formFields":[{"id":"email","error":"This email already exists. Please sign in instead."}]}

If it's important, a bug was caught on FastAPI and supertokens-python version is 0.12.9.

[igoose1]

As I can see, that happens in these lines.

supertokens-python/supertokens_python/recipe/emailpassword/api/signup.py

Lines 48 to 65 in 8567ab5

	response = await api_implementation.sign_up_post(
	form_fields, api_options, user_context
	)
	if isinstance(response, SignUpPostOkResult):
	return send_200_response(response.to_json(), api_options.response)
	if isinstance(response, GeneralErrorResponse):
	return send_200_response(response.to_json(), api_options.response)
	return raise_form_field_exception(
	"EMAIL_ALREADY_EXISTS_ERROR",
	[
	ErrorFormField(
	id="email",
	error="This email already exists. Please sign in instead.",
	)
	],
	)

.

[rishabhpoddar]

Fair enough. We didn't have it originally cause we users would use type checking in their code.

Fixing this is not a priority for us at the moment though, so feel free to make PRs for this yourself :)

[igoose1]

@rishabhpoddar, good point! I checked in our current codebase. For some reasons the return value was set to Any and mypy didn't complain. It needs to be changed to an actual Response. (I know you don't support mypy tho.)

Current fix is in master...igoose1:supertokens-python:fix-unexpected-behavior-in-sign_up_post. That's not covered with tests and had been holded until I write them. But after your message I see why people won't get that situation as often as I expected.

As it requires more work to finish PR (tests, similar fixes for other receipes) and doesn't affect most of users, I'm closing an issue.

[rishabhpoddar]

Well, i would still keep this issue open. And one could gradually add this fix on a per API basis. So if someone does, then great.