Duplicate "session_id" in response of API on pre-release. about langflow HOT 6 OPEN

To ensure that each API call generates an independent session_id instead of having the same session_id for all API calls, you can use the session_id_generator function provided in the utils.py file. This function generates a unique ID using a combination of uppercase letters and digits. You can integrate this into your API call logic to generate a new session_id for each request.

Here is an example of how you might modify your API call handler to generate a new session_id for each call:

import random
import string

def session_id_generator(size=6):
    return "".join(random.SystemRandom().choices(string.ascii_uppercase + string.digits, k=size))

def handle_api_call(request):
    session_id = session_id_generator()
    # Process the request with the new session_id
    # Your existing logic here
    return response

This ensures that every time handle_api_call is invoked, a new session_id is generated using session_id_generator, providing a unique identifier for each API call.

Additionally, you can refer to the SessionService class in the service.py file for more advanced configurations. This class allows you to generate and manage unique session IDs, which can be useful if you need more control over the session management process.

from typing import TYPE_CHECKING, Optional

from langflow.interface.run import build_sorted_vertices
from langflow.services.base import Service
from langflow.services.session.utils import compute_dict_hash, session_id_generator

if TYPE_CHECKING:
    from langflow.services.cache.base import BaseCacheService


class SessionService(Service):
    name = "session_service"

    def __init__(self, cache_service):
        self.cache_service: "BaseCacheService" = cache_service

    async def load_session(self, key, data_graph: Optional[dict] = None):
        # Check if the data is cached
        if key in self.cache_service:
            return self.cache_service.get(key)

        if key is None:
            key = self.generate_key(session_id=None, data_graph=data_graph)
        if data_graph is None:
            return (None, None)
        # If not cached, build the graph and cache it
        graph, artifacts = await build_sorted_vertices(data_graph)

        self.cache_service.set(key, (graph, artifacts))

        return graph, artifacts

    def build_key(self, session_id, data_graph):
        json_hash = compute_dict_hash(data_graph)
        return f"{session_id}{':' if session_id else ''}{json_hash}"

    def generate_key(self, session_id, data_graph):
        # Hash the JSON and combine it with the session_id to create a unique key
        if session_id is None:
            # generate a 5 char session_id to concatenate with the json_hash
            session_id = session_id_generator()
        return self.build_key(session_id, data_graph=data_graph)

    def update_session(self, session_id, value):
        self.cache_service.set(session_id, value)

    def clear_session(self, session_id):
        self.cache_service.delete(session_id)

This class can be used to generate unique session IDs with additional configuration options, ensuring that each API call has a distinct session_id ^[1][2][3][4].

To continue talking to Dosu, mention @dosu.

from langflow.

how can we continue the same conversation ?

from langflow.

In the case of session IDs, we first undergo an initialization process where we call the API without specifying any session value. We then store the generated session ID received in the response and include this session ID in the API calls starting from the second chat onwards to ensure continuity without starting a new session. However, when not using Redis or similar tools, if multiple workers are running, they may not be able to find the same session, resulting in errors indicating that the session does not exist. Despite this, after looping 3-5 times, the session is eventually found and maintained. The developer has mentioned that this is a serialization issue with Vertex. For our actual service, we prioritize ensuring that it works, even if it means looping and retrying, despite the unnecessary connections that occur as a result.

from langflow.

In the case of session IDs, we first undergo an initialization process where we call the API without specifying any session value. We then store the generated session ID received in the response and include this session ID in the API calls starting from the second chat onwards to ensure continuity without starting a new session. However, when not using Redis or similar tools, if multiple workers are running, they may not be able to find the same session, resulting in errors indicating that the session does not exist. Despite this, after looping 3-5 times, the session is eventually found and maintained. The developer has mentioned that this is a serialization issue with Vertex. For our actual service, we prioritize ensuring that it works, even if it means looping and retrying, despite the unnecessary connections that occur as a result.

Thanks for explain.
The generated session ID received in the response that you said is same for same flow in 1.0.0.a49.

from langflow.

"tweaks": {
"session_id": "69c15b5397326"
}

In the case of session IDs, we first undergo an initialization process where we call the API without specifying any session value. We then store the generated session ID received in the response and include this session ID in the API calls starting from the second chat onwards to ensure continuity without starting a new session. However, when not using Redis or similar tools, if multiple workers are running, they may not be able to find the same session, resulting in errors indicating that the session does not exist. Despite this, after looping 3-5 times, the session is eventually found and maintained. The developer has mentioned that this is a serialization issue with Vertex. For our actual service, we prioritize ensuring that it works, even if it means looping and retrying, despite the unnecessary connections that occur as a result.

Thanks for explain. The generated session ID received in the response that you said is same for same flow in 1.0.0.a49.

It seems like there might have been a change in how sessions are created. Following your instructions, I confirmed that it returns an HTML response. When specifying the session ID in tweaks, the same session (converted) is returned in the response. I'm not sure if this is a bug or intentional.

"tweaks": {
"session_id": "69c15b5397326"
}

from langflow.

Considering the recent setup, it seems that the addition of the webhook component has introduced a higher level of categorization.

from langflow.