-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable conversation sessions by default #6934
Conversation
@@ -29,6 +29,17 @@ how you can migrate from one version to another. | |||
component in your `policies` configuration (`config.yml`) you can replace it | |||
with `TEDPolicy`. It accepts the same configuration parameters. | |||
|
|||
* [Conversation sessions](domain.mdx#session-configuration) are now enabled by default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The title of the targeted section is currently Session Configuration
. I'd vote for renaming this to Conversation Sessions
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mm, I think it makes the most sense to have the title of the section to reflect the high level keys in the domain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then let's leave it as it is.
This enables sessions by default.
ca3cd9d
to
3ee3572
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, this behavior makes more sense with regards to the "default configuration" we already reference in the docs 👌
@@ -185,7 +184,6 @@ def from_dict(cls, data: Dict) -> "Domain": | |||
def _get_session_config(session_config: Dict) -> SessionConfig: | |||
session_expiration_time_min = session_config.get(SESSION_EXPIRATION_TIME_KEY) | |||
|
|||
# TODO: 2.0 reconsider how to apply sessions to old projects and legacy trackers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we've just decided to leave them as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I changed the default from 0
to 60
which essentially enables them by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i guess i assumed that this note was about "should we read all of the conversations from 2018 as one conversation even if we introduce sessions now? with regards to applying them to legacy trackers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay. Yes, these will have sessions enabled, too, now
Proposed changes:
session_config
is given in the domain. This is a breaking change in contrast to Rasa Open Source 1 where this would result in disabled conversation sessions. The default value forsession_expiration_time
is the same one which we have been using in ourrasa init
project.rasa.shared
).Status (please check what you already did):
black
(please check Readme for instructions)