Fix user ID always default on every shell session.

[VictorCoCo]

Proposed changes:

It is hard to check the bot's functionality after making updates and/or changes, especially when
there is a need to maintain a session for a user.

For example:
When using a CoCo component, a session identifier needs to be maintained throughout and when the user ID
doesn't change from session to session, the conversation maintains the context from the previous shell session.

• ...

Status (please check what you already did):

• added some tests for the functionality
• updated the documentation
• updated the changelog (please check changelog for instructions)
• reformat files using black (please check Readme for instructions)

[claassistantio]

All committers have signed the CLA.

[akelad]

Thanks for submitting this PR, we'll give it a review as soon as possible.

[ricwo]

I think the change makes sense in general - please have a look at the comments.

Would you mind adding a changelog entry? You can find the instructions in the README (you'll have to create an issue for reference in the changelog entry).

Thanks a lot for your contribution! 🎉

[ricwo]

we use the hex version of UUID4 elsewhere - it would be good to keep that consistent

Suggested change

	CONSOLE_SESSION_USER_ID = str(uuid.uuid4())
	CONSOLE_SESSION_USER_ID = uuid.uuid4().hex

[ricwo]

Thanks a lot for the changes 👍

[ricwo]

@VictorCoCo can you please make sure test_console_input() passes?

[erohmensing]

@ricwo do you think it is worth it to be able to configure the id being set the same every time (or set a specific id, with default random)? I'm wondering if there is anyone who is currently banking on pulling the tracker from "default" every time who will have trouble in the future with an unpredictable conversation ID, especially in a script to pull trackers.

[VictorCoCo]

@ricwo do you think it is worth it to be able to configure the id being set the same every time (or set a specific id, with default random)? I'm wondering if there is anyone who is currently banking on pulling the tracker from "default" every time who will have trouble in the future with an unpredictable conversation ID, especially in a script to pull trackers.

@erohmensing Do you think passing the sender_id to the shell command as an optional argument would help?

[ricwo]

yes @erohmensing @VictorCoCo I think that is reasonable - as you suggested the easiest thing would be to add a command-line argument to rasa shell (--conversation-id)

[VictorCoCo]

@erohmensing Added

--conversation-id

missed your comment, will change --sender-id to --conversation-id

[ricwo]

@VictorCoCo can you please make sure all tests pass? feel free to request a review from me again afterwards

[ricwo]

Looks great, thanks for your changes 👍

[ricwo]

@VictorCoCo would you mind fixing the failing build?

[VictorCoCo]

@VictorCoCo would you mind fixing the failing build?

I see only an issue on code climate, an unrelated code issue. Maybe a permission issue, Do you want me to squash it?

[chkoss]

@ricwo Would it be better to default to generating a random ID when rasa shell is called instead of fixing it here as a constant?

The reason for this suggestion is: If you have a persistent tracker store and run rasa shell, you would want to start from scratch with a new conversation id and not at whichever state the last session with a default id was in.
(We were also discussing that in the PR that adds such an argument for rasa interactive: #5243.)

[VictorCoCo]

I agree, It was the way I first changed it. @ricwo @erohmensing I am ok with changing it, What is your opinion?

[ricwo]

@chkoss yes but this is a separate functionality and should probably be controlled with a different command-line argument, something like --assign-random-conversation-id

@VictorCoCo your initial implementation assigned a random user ID with every new shell session, and made it impossible to use a deterministic one. being able to define a conversation ID as a command-line argument and having the script choose a random one are two separate issues. whatever the default behaviour, there needs to remain the possibility of a deterministic conversation ID

[tmbo]

@VictorCoCo we'd love to make this part of the next release next week. Regarding the discussion, I think we should be consistent. By default we should generate a random id. If the user wants to use a specifc one, they can use --conversation-id to set it. (https://github.com/RasaHQ/rasa/pull/5243/files).

Do you mind changing that? Otherwise the PR looks great and we are ready to merge 🚀

inconsistend API, needs to be fixed before merge

[VictorCoCo]

@VictorCoCo we'd love to make this part of the next release next week. Regarding the discussion, I think we should be consistent. By default we should generate a random id. If the user wants to use a specifc one, they can use --conversation-id to set it. (https://github.com/RasaHQ/rasa/pull/5243/files).

Do you mind changing that? Otherwise the PR looks great and we are ready to merge 🚀

Great decision. I will make the changes until Monday.

[tmbo]

Perfect - we'll cut the release on Tuesday so Monday sounds great. Please shoot me a message once you are ready 🙂

[tmbo]

great work @VictorCoCo thanks a lot for jumping on this and getting the change ready to be merged 🚀