why does DialogFlow `createContext` API require a session?

Question

I'm managing content for a dialogflow bot via the API rather than the GUI.

I can create basic intents and entities but having real trouble assigning contexts in/out to intents.

Basically using the "name" of a context in an intent seems to have no effect.

Do I have to use the path or ID of a context?

So then I tried to create some contexts and see if there is more data there like a path or name to use. However, this gives different problems:

Creating a context seems to require a session. https://github.com/googleapis/nodejs-dialogflow/blob/master/samples/resource.js#L309

async function createContext( projectId, sessionId, contextId, lifespanCount)

I just want to assign a outputContext to an intent, so this is an authoring time setting I can do usually through the GUI, not a run time context on the user (session).

So, I don't understand why a session is needed - surely that would be for a temporary user session, so eg if you were setting a context for that user, that session.

Any help or nodeJS sample code would be appreciated.

creating an intent https://cloud.google.com/dialogflow/docs/reference/rest/v2/projects.agent.intents/create#query-parameters

takes inputContextNAMES

  "inputContextNames": [
    string
  ],

but outputContexts are Objects

  "outputContexts": [
    {
      object (Context)
    }
  ],

and context Objects seem to be related to dynamic sessions where they fall in the API docs tree and need a session.

So, kinda flummoxed why input/output contexts are treated differently.

API docs to create a context but this is only in a session https://cloud.google.com/dialogflow/docs/reference/rest/v2/projects.agent.sessions.contexts/create

Victor Victor · Accepted Answer · 2020-04-20T05:48:16

Long story short: You probably want this: https://cloud.google.com/dialogflow/docs/reference/rest/v2/projects.agent.intents

Let's clear the decks and untangle this knot because there's a few things going on.

First thing, let's forget about contexts-- both input & the output contexts-- & just think about pizza.

Imagine you built a pizza shop bot that lets you order only 1 kind of pizza & 1 kind of drink & gives you the option to you pay either by cash or credit card.

A conversation flow w/o any problems would look like this:

User: I want a pizza

Agent: Ok 1 pizza $5. Do you want a drink?

User: Yes

Agent: Ok, 1 pizza + 1 drink is $10. Do you want to pay with credit card?

Agent: If you say no you can pay with cash

User: No

Agent: Ok $10 cash (+ bot-tip of course)

You can imagine the other conversation branches & options, but the main thing to notice is that there are multiple points where the user could indicate "yes" or "no." DialogFlow "knows" what the user is referring to because of contexts + sessions.

Ex. Without any context

User: No.

Agent: What are you talking about?

Agent: Do you mean no drink? Do you mean no credit card? Do you mean no pizza?

3 Ideas:

1) Session: A random string (no longer than 36 characters) that gets attached to each "round" of the conversation, ex: 1234567

2) Context: An idea in DialogFlow that does two things: (1) stash data between "turns" of a conversation & (2) influence which intent gets matched if multiple intent are eligible to be invoked. ex. {name:'context name', parameters: {}, languageCode: 'en-US'}

3) contextPath/sessionPath? These are just DialogFlow API identifiers that scope your requests to whatever project your agent is associated. If you're interacting w/ the DialogFlow API you will probably be using these

ex. Session Path

session id is 12456789
project id is gcp-abcbots-xxx-545

sessionPath would be:
projects/gcp-abcbots-xxx-545/agent/sessions/123456789

ex. Context Path: Session Path + Context

session id is 12456789
project id is gcp-abcbots-xxx-545
Context is : {name: 'context_1', parameters: {}, languageCode: 'en_US'}
ContextName is : context_1


contextPath is:
projects/gcp-abcbots-xxx-545/agent/sessions/123456789/contexts/context_1

ContextPath = sessionPath/contexts/context_1

Context more broadly generally to the idea of maintaining "state" during a series of ping-pong interactions between a user and a conversational system. (A "conversation" for our purposes is for us at the end of day just a series of API calls at each "turn" of the conversation.)

Example if you say "what's the weather like in Minneapolis?", you get an answer, then ask again "what's the weather going to be like there next week?" you should reasonably expect the agent should maintain the context that you're talking about Minneapolis.

Your Question: why does DialogFlow createContext API require a session?

With createContext what you're really doing is making a context active to the current "conversation" (which really means the new context gets attached to the whatever "session.") That's why you "need" a session or sessionPath because what you're doing is attaching a context to a session.

If you're talking about attaching an input/output context to an intent that doesn't require a session. You can do that via API or the web console

Output Contexts/Input Contexts

Input & output contexts in DialogFlow are all about influencing which intents will be matched. But think of them this way too: input/output contexts are really about getting contexts attached to sessions at the right time.

For example, if an intent in DialogFlow has an output context-- whenever it's "done" that output context will become "active" or associated with a current user's session. Any intents with a matching input context which is active in a session are more likely to be matched.

tl;dr: You can create input/output contexts & attach them to intents-- that doesn't need a session, you just need an intent. If you want to "create" a context that is active in the conversation you need a session OR you need to match an intent that has an output context and that context then becomes "active" in the session

why does DialogFlow `createContext` API require a session?

1 Answers