Hello world

Originally posted by @Onyekachi1234 in https://github.com/Onyekachi1234/cyrilserver/issues/3

Originally posted by @Onyekachi1234 in https://github.com/Onyekachi1234/cyrilserver/issues/3

Read-me


ERROR:  zep_python.exceptions.APIError: API error: {'status_code': 502, 'message': ''}

Hello, I'm not very good at English. If possible, please help me
This is my detailed error message：
File "d:\360MoveData\Users\Administrator\Desktop\bot\memory.py", line 119, in <module>
memory.chat_memory.add_message(
File "D:\ana\envs\pbot\lib\site-packages\langchain\memory\chat_message_histories\zep.py", line 168, in add_message
self.zep_client.add_memory(self.session_id, zep_memory)
File "D:\ana\envs\pbot\lib\site-packages\zep_python\zep_client.py", line 400, in add_memory
self._handle_response(response)
File "D:\ana\envs\pbot\lib\site-packages\zep_python\zep_client.py", line 111, in _handle_response
raise APIError(response)
zep_python.exceptions.APIError: API error: {'status_code': 502, 'message': ''}

This is my code, almost copied from the zepmemory in Python. langchain:
from langchain.memory import ZepMemory
from langchain.retrievers import ZepRetriever
from langchain import OpenAI
from langchain.schema import HumanMessage, AIMessage
from langchain.utilities import WikipediaAPIWrapper
from langchain.agents import initialize_agent, AgentType, Tool
from uuid import uuid4

ZEP_API_URL =  "http://localhost:8000"
ZEP_API_KEY = "gzTpR0Ace87a6Z-0KMmhlzfMtjsSkQXyjfSdIUFjgKN5cNBLaeOZW1Nq5O6lQ_TNzFh3wKRa6I_NksHEKtloYA"

session_id = str(uuid4())

import getpass

openai_key = "sk-***************************************"

zep_api_key = ZEP_API_KEY

search = WikipediaAPIWrapper()
tools = [
    Tool(
        name="Search",
        func=search.run,
        description="useful for when you need to search online for answers. You should ask targeted questions",
    ),
]

memory = ZepMemory(
    session_id=session_id,
    url=ZEP_API_URL,
    api_key=zep_api_key,
    memory_key="chat_history",
)

llm = OpenAI(temperature=0, openai_api_key=openai_key)
agent_chain = initialize_agent(
    tools,
    llm,
    agent=AgentType.CONVERSATIONAL_REACT_DESCRIPTION,
    verbose=True,
    memory=memory,
)

test_history = [
    {"role": "human", "content": "Who was Octavia Butler?"},
    {
        "role": "ai",
        "content": (
            "Octavia Estelle Butler (June 22, 1947 – February 24, 2006) was an American"
            " science fiction author."
        ),
    },
    {"role": "human", "content": "Which books of hers were made into movies?"},
    {
        "role": "ai",
        "content": (
            "The most well-known adaptation of Octavia Butler's work is the FX series"
            " Kindred, based on her novel of the same name."
        ),
    },
    {"role": "human", "content": "Who were her contemporaries?"},
    {
        "role": "ai",
        "content": (
            "Octavia Butler's contemporaries included Ursula K. Le Guin, Samuel R."
            " Delany, and Joanna Russ."
        ),
    },
    {"role": "human", "content": "What awards did she win?"},
    {
        "role": "ai",
        "content": (
            "Octavia Butler won the Hugo Award, the Nebula Award, and the MacArthur"
            " Fellowship."
        ),
    },
    {
        "role": "human",
        "content": "Which other women sci-fi writers might I want to read?",
    },
    {
        "role": "ai",
        "content": "You might want to read Ursula K. Le Guin or Joanna Russ.",
    },
    {
        "role": "human",
        "content": (
            "Write a short synopsis of Butler's book, Parable of the Sower. What is it"
            " about?"
        ),
    },
    {
        "role": "ai",
        "content": (
            "Parable of the Sower is a science fiction novel by Octavia Butler,"
            " published in 1993. It follows the story of Lauren Olamina, a young woman"
            " living in a dystopian future where society has collapsed due to"
            " environmental disasters, poverty, and violence."
        ),
        "metadata": {"foo": "bar"},
    },
]

for msg in test_history:
    memory.chat_memory.add_message(
        HumanMessage(content=msg["content"])
        if msg["role"] == "human"
        else AIMessage(content=msg["content"]),
        metadata=msg.get("metadata", {}),
    )

agent_chain.run(
    input="What is the book's relevance to the challenges facing contemporary society?",
)

The server uses Docker self deployment, and the ports are all default. Zep: 8000:8000, zep npl: 8080:8080, zep postgres: 5432:5432,
The server is running normally without any errors, and can browse <IP_ADDRESS>:8080 normally. Using telnet, it is possible to ping ports 8080 and 8000 normally
If you need any more information, please let me know. I would be happy to provide it. Thank you. I am not very proficient in English, and all English is translated through translation software. If there is any offense, I sorry

I'm able to run your code as-is. I noticed that your JWT token (the ZEP_API_KEY) is not a valid base64-encoded token. JWT tokens all start with the characters ey. It's possible you're using your API secret as your token. Please would you carefully review the the authentication guide below, in particular Step 3, in order to ensure you've correctly set this up?
https://docs.getzep.com/deployment/auth/
Some additional things to check:

You're running the latest Zep server (currently v0.8.1)
You're using the latest Zep Python package (currently v0.33).

You’ll need to install go if you’d like to compile Zep: https://go.dev/doc/install
Alternatively, you can generate a JWT token using the jwt.io website:
https://jwt.io/
The algorithm should be HS256 and the payload an empty {}.
Note that you’ll be pasting your secret into a form on the website. I don’t believe the form submits to the site backend and the site is run by a reputable company. Nevertheless, you should be aware that this there is a risk to doing this.

Would you please share the Zep logs? Thanks

Would you please share the Zep logs? Thanks
Of course, I would be happy to. Here is the log file information I found on Docker

Firstly, zep's logs：
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=warning msg=".env file not found or unable to load. This warning can be ignored if Zep is run using docker compose with env_file defined or you are passing ENV variables."
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="Log level set to: info"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="Starting zep server version 0.8.1-c204bed (2023-07-14T07:50:34+0000)"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="Using memory store: postgres"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="Starting purge delete processor. Purging every 1h0m0s"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="Initializing extractors"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="SummaryExtractor attached to memory store"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="EmbeddingExtractor attached to memory store"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="TokenCountExtractor attached to memory store"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="EntityExtractor attached to memory store"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="IntentExtractor attached to memory store"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="JWT authentication required"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="Listening on: :8000"
2023-07-25 14:22:51 time="2023-07-25T06:22:51Z" level=info msg="completed purging memory store"

Next is the logs of zep-nlp：
2023-07-21 17:23:20 INFO:     Started server process [1]
2023-07-21 17:23:20 INFO:     Waiting for application startup.
2023-07-21 17:23:20 INFO:     Application startup complete.
2023-07-21 17:23:20 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-21 17:34:25 INFO:     Shutting down
2023-07-21 17:34:25 INFO:     Waiting for application shutdown.
2023-07-21 17:34:25 INFO:     Application shutdown complete.
2023-07-21 17:34:25 INFO:     Finished server process [1]
2023-07-22 15:11:32 INFO:     Started server process [1]
2023-07-22 15:11:32 INFO:     Waiting for application startup.
2023-07-22 15:11:32 INFO:     Application startup complete.
2023-07-22 15:11:32 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-22 17:45:25 INFO:     Shutting down
2023-07-22 17:45:25 INFO:     Waiting for application shutdown.
2023-07-22 17:45:25 INFO:     Application shutdown complete.
2023-07-22 17:45:25 INFO:     Finished server process [1]
2023-07-22 17:50:21 INFO:     Started server process [1]
2023-07-22 17:50:21 INFO:     Waiting for application startup.
2023-07-22 17:50:21 INFO:     Application startup complete.
2023-07-22 17:50:21 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-23 08:21:27 INFO:     Shutting down
2023-07-23 08:21:27 INFO:     Waiting for application shutdown.
2023-07-23 08:21:27 INFO:     Application shutdown complete.
2023-07-23 08:21:27 INFO:     Finished server process [1]
2023-07-24 10:09:35 INFO:     Started server process [1]
2023-07-24 10:09:35 INFO:     Waiting for application startup.
2023-07-24 10:09:35 INFO:     Application startup complete.
2023-07-24 10:09:35 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-24 10:34:03 WARNING:  Invalid HTTP request received.
2023-07-24 14:19:07 WARNING:  Invalid HTTP request received.
2023-07-24 14:22:42 INFO:     Shutting down
2023-07-24 14:22:42 INFO:     Waiting for application shutdown.
2023-07-24 14:22:42 INFO:     Application shutdown complete.
2023-07-24 14:22:42 INFO:     Finished server process [1]
2023-07-24 14:23:34 INFO:     Started server process [1]
2023-07-24 14:23:34 INFO:     Waiting for application startup.
2023-07-24 14:23:34 INFO:     Application startup complete.
2023-07-24 14:23:34 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-24 14:31:32 INFO:     Shutting down
2023-07-24 14:31:32 INFO:     Waiting for application shutdown.
2023-07-24 14:31:32 INFO:     Application shutdown complete.
2023-07-24 14:31:32 INFO:     Finished server process [1]
2023-07-24 14:31:38 INFO:     Started server process [1]
2023-07-24 14:31:38 INFO:     Waiting for application startup.
2023-07-24 14:31:38 INFO:     Application startup complete.
2023-07-24 14:31:38 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-24 17:45:15 INFO:     Shutting down
2023-07-24 17:45:15 INFO:     Waiting for application shutdown.
2023-07-24 17:45:15 INFO:     Application shutdown complete.
2023-07-24 17:45:15 INFO:     Finished server process [1]
2023-07-25 08:27:42 INFO:     Started server process [1]
2023-07-25 08:27:42 INFO:     Waiting for application startup.
2023-07-25 08:27:42 INFO:     Application startup complete.
2023-07-25 08:27:42 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-25 09:45:28 INFO:     Shutting down
2023-07-25 09:45:28 INFO:     Waiting for application shutdown.
2023-07-25 09:45:28 INFO:     Application shutdown complete.
2023-07-25 09:45:28 INFO:     Finished server process [1]
2023-07-25 10:03:01 INFO:     Started server process [1]
2023-07-25 10:03:01 INFO:     Waiting for application startup.
2023-07-25 10:03:01 INFO:     Application startup complete.
2023-07-25 10:03:01 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-25 14:19:17 INFO:     Shutting down
2023-07-25 14:19:17 INFO:     Waiting for application shutdown.
2023-07-25 14:19:17 INFO:     Application shutdown complete.
2023-07-25 14:19:17 INFO:     Finished server process [1]
2023-07-25 14:22:43 INFO:     Started server process [1]
2023-07-25 14:22:43 INFO:     Waiting for application startup.
2023-07-25 14:22:43 INFO:     Application startup complete.
2023-07-25 14:22:43 INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-07-25 14:50:59 INFO:     Shutting down
2023-07-25 14:50:59 INFO:     Waiting for application shutdown.
2023-07-25 14:50:59 INFO:     Application shutdown complete.
2023-07-25 14:50:59 INFO:     Finished server process [1]
2023-07-22 16:39:53 INFO:     <IP_ADDRESS>:45264 - "GET / HTTP/1.1" 307 Temporary Redirect
2023-07-22 16:39:53 INFO:     <IP_ADDRESS>:45264 - "GET /docs HTTP/1.1" 200 OK
2023-07-22 16:40:03 INFO:     <IP_ADDRESS>:51106 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-22 16:40:51 INFO:     <IP_ADDRESS>:51252 - "GET /healthz HTTP/1.1" 200 OK
2023-07-22 16:40:55 INFO:     <IP_ADDRESS>:51266 - "GET /healthz HTTP/1.1" 200 OK
2023-07-22 16:41:03 INFO:     <IP_ADDRESS>:55932 - "GET /healthz HTTP/1.1" 200 OK
2023-07-22 16:41:04 INFO:     <IP_ADDRESS>:55932 - "GET /healthz HTTP/1.1" 200 OK
2023-07-22 16:42:03 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:03 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:03 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:42:04 INFO:     <IP_ADDRESS>:47712 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 16:57:40 INFO:     <IP_ADDRESS>:56770 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:01 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:06 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:02:06 INFO:     <IP_ADDRESS>:60404 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:06 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:09 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:03:09 INFO:     <IP_ADDRESS>:58916 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:33 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:34 INFO:     <IP_ADDRESS>:32938 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:39 INFO:     <IP_ADDRESS>:49528 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:07:39 INFO:     <IP_ADDRESS>:49528 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:00 INFO:     <IP_ADDRESS>:54846 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:06 INFO:     <IP_ADDRESS>:54856 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:08:06 INFO:     <IP_ADDRESS>:54856 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:24 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:27 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:25:27 INFO:     <IP_ADDRESS>:59968 - "POST /entities HTTP/1.1" 200 OK
2023-07-22 17:36:48 INFO:     <IP_ADDRESS>:33544 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-22 18:06:27 INFO:     <IP_ADDRESS>:47342 - "GET / HTTP/1.1" 307 Temporary Redirect
2023-07-22 18:06:27 INFO:     <IP_ADDRESS>:47342 - "GET /docs HTTP/1.1" 200 OK
2023-07-22 18:06:27 INFO:     <IP_ADDRESS>:47342 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-22 18:06:30 INFO:     <IP_ADDRESS>:47350 - "GET /docs HTTP/1.1" 200 OK
2023-07-22 18:06:30 INFO:     <IP_ADDRESS>:47350 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-24 10:10:55 INFO:     <IP_ADDRESS>:55888 - "GET / HTTP/1.1" 307 Temporary Redirect
2023-07-24 10:10:55 INFO:     <IP_ADDRESS>:55888 - "GET /docs HTTP/1.1" 200 OK
2023-07-24 10:10:56 INFO:     <IP_ADDRESS>:55888 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-24 10:11:22 INFO:     <IP_ADDRESS>:57640 - "POST /api/v1/sessions/1400cfea-cd4e-4a90-8694-008864c71404/memory HTTP/1.1" 404 Not Found
2023-07-24 10:12:42 INFO:     <IP_ADDRESS>:36658 - "POST /api/v1/sessions/c7a3ffdf-cd9e-4031-8e8f-e748241fe551/memory HTTP/1.1" 404 Not Found
2023-07-24 10:15:20 INFO:     <IP_ADDRESS>:35192 - "POST /api/v1/sessions/7024ec46-ae26-4968-8855-4fec9edc75a1/memory HTTP/1.1" 404 Not Found
2023-07-24 10:22:40 INFO:     <IP_ADDRESS>:38210 - "GET / HTTP/1.1" 307 Temporary Redirect
2023-07-24 10:22:40 INFO:     <IP_ADDRESS>:38210 - "GET /docs HTTP/1.1" 200 OK
2023-07-24 10:22:40 INFO:     <IP_ADDRESS>:38210 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-24 10:24:56 INFO:     <IP_ADDRESS>:49656 - "POST /api/v1/sessions/763f01ea-57d5-4e00-aac2-9775cbfedfcb/memory HTTP/1.1" 404 Not Found
2023-07-24 10:36:06 INFO:     <IP_ADDRESS>:45346 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-24 10:39:00 INFO:     <IP_ADDRESS>:50144 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-25 08:48:48 INFO:     <IP_ADDRESS>:35480 - "GET / HTTP/1.1" 307 Temporary Redirect
2023-07-25 08:48:48 INFO:     <IP_ADDRESS>:35480 - "GET /docs HTTP/1.1" 200 OK
2023-07-25 08:48:50 INFO:     <IP_ADDRESS>:35480 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-25 09:08:03 INFO:     <IP_ADDRESS>:56698 - "GET /openapi.json HTTP/1.1" 200 OK
2023-07-25 09:42:15 INFO:     <IP_ADDRESS>:54904 - "GET /openapi.json HTTP/1.1" 200 OK

Next is the logs of zep postgres
2023-07-21 17:23:08 The files belonging to this database system will be owned by user "postgres".
2023-07-21 17:23:08 This user must also own the server process.
2023-07-21 17:23:08
2023-07-21 17:23:08 The database cluster will be initialized with locale "en_US.utf8".
2023-07-21 17:23:08 The default database encoding has accordingly been set to "UTF8".
2023-07-21 17:23:08 The default text search configuration will be set to "english".
2023-07-21 17:23:08
2023-07-21 17:23:08 Data page checksums are disabled.
2023-07-21 17:23:08
2023-07-21 17:23:08 fixing permissions on existing directory /var/lib/postgresql/data ... ok
2023-07-21 17:23:08 creating subdirectories ... ok
2023-07-21 17:23:08 selecting dynamic shared memory implementation ... posix
2023-07-21 17:23:08 selecting default max_connections ... 100
2023-07-21 17:23:08 selecting default shared_buffers ... 128MB
2023-07-21 17:23:08 selecting default time zone ... Etc/UTC
2023-07-21 17:23:08 creating configuration files ... ok
2023-07-21 17:23:09 initdb: warning: enabling "trust" authentication for local connections
2023-07-21 17:23:09 initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
2023-07-21 17:23:09 2023-07-21 09:23:09.684 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-21 17:23:09 2023-07-21 09:23:09.685 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-21 17:23:09 2023-07-21 09:23:09.685 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-21 17:23:09 2023-07-21 09:23:09.691 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-21 17:23:09 2023-07-21 09:23:09.698 UTC [63] LOG:  database system was shut down at 2023-07-21 09:23:09 UTC
2023-07-21 17:23:09 2023-07-21 09:23:09.708 UTC [1] LOG:  database system is ready to accept connections
2023-07-21 17:28:09 2023-07-21 09:28:09.798 UTC [61] LOG:  checkpoint starting: time
2023-07-21 17:28:30 2023-07-21 09:28:30.583 UTC [61] LOG:  checkpoint complete: wrote 210 buffers (1.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=20.753 s, sync=0.022 s, total=20.785 s; sync files=102, longest=0.008 s, average=0.001 s; distance=1002 kB, estimate=1002 kB
2023-07-21 17:34:25 2023-07-21 09:34:25.129 UTC [1] LOG:  received fast shutdown request
2023-07-21 17:34:25 2023-07-21 09:34:25.138 UTC [1] LOG:  aborting any active transactions
2023-07-21 17:34:25 2023-07-21 09:34:25.141 UTC [1] LOG:  background worker "logical replication launcher" (PID 66) exited with exit code 1
2023-07-21 17:34:25 2023-07-21 09:34:25.143 UTC [61] LOG:  shutting down
2023-07-21 17:34:25 2023-07-21 09:34:25.146 UTC [61] LOG:  checkpoint starting: shutdown immediate
2023-07-21 17:34:25 2023-07-21 09:34:25.337 UTC [61] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.194 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=902 kB
2023-07-21 17:34:25 2023-07-21 09:34:25.345 UTC [1] LOG:  database system is shut down
2023-07-22 15:11:26 2023-07-22 07:11:26.796 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-22 15:11:26 2023-07-22 07:11:26.797 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-22 15:11:26 2023-07-22 07:11:26.797 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-22 15:11:26 2023-07-22 07:11:26.802 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-22 15:11:26 2023-07-22 07:11:26.809 UTC [29] LOG:  database system was shut down at 2023-07-21 09:34:25 UTC
2023-07-22 15:11:26 2023-07-22 07:11:26.825 UTC [1] LOG:  database system is ready to accept connections
2023-07-22 15:11:37 2023-07-22 07:11:37.400 UTC [47] ERROR:  relation "session_session_id_idx" already exists
2023-07-22 15:11:37 2023-07-22 07:11:37.400 UTC [47] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-22 15:11:37 2023-07-22 07:11:37.402 UTC [47] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-22 15:11:37 2023-07-22 07:11:37.402 UTC [47] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-22 15:11:37 2023-07-22 07:11:37.403 UTC [47] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-22 15:11:37 2023-07-22 07:11:37.403 UTC [47] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-22 15:11:37 2023-07-22 07:11:37.404 UTC [47] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-22 15:11:37 2023-07-22 07:11:37.404 UTC [47] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-22 15:16:26 2023-07-22 07:16:26.830 UTC [27] LOG:  checkpoint starting: time
2023-07-22 15:16:27 2023-07-22 07:16:27.361 UTC [27] LOG:  checkpoint complete: wrote 8 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.505 s, sync=0.011 s, total=0.531 s; sync files=5, longest=0.009 s, average=0.003 s; distance=0 kB, estimate=0 kB
2023-07-22 16:46:27 2023-07-22 08:46:27.537 UTC [27] LOG:  checkpoint starting: time
2023-07-22 16:46:29 2023-07-22 08:46:29.670 UTC [27] LOG:  checkpoint complete: wrote 22 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=2.107 s, sync=0.006 s, total=2.134 s; sync files=14, longest=0.002 s, average=0.001 s; distance=32 kB, estimate=32 kB
2023-07-22 17:01:27 2023-07-22 09:01:27.882 UTC [27] LOG:  checkpoint starting: time
2023-07-22 17:01:29 2023-07-22 09:01:29.610 UTC [27] LOG:  checkpoint complete: wrote 18 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.706 s, sync=0.013 s, total=1.729 s; sync files=14, longest=0.009 s, average=0.001 s; distance=57 kB, estimate=57 kB
2023-07-22 17:06:27 2023-07-22 09:06:27.636 UTC [27] LOG:  checkpoint starting: time
2023-07-22 17:06:33 2023-07-22 09:06:33.085 UTC [27] LOG:  checkpoint complete: wrote 55 buffers (0.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=5.415 s, sync=0.008 s, total=5.450 s; sync files=30, longest=0.002 s, average=0.001 s; distance=199 kB, estimate=199 kB
2023-07-22 17:11:27 2023-07-22 09:11:27.126 UTC [27] LOG:  checkpoint starting: time
2023-07-22 17:11:31 2023-07-22 09:11:31.881 UTC [27] LOG:  checkpoint complete: wrote 48 buffers (0.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=4.713 s, sync=0.027 s, total=4.755 s; sync files=30, longest=0.015 s, average=0.001 s; distance=201 kB, estimate=201 kB
2023-07-22 17:16:27 2023-07-22 09:16:27.920 UTC [27] LOG:  checkpoint starting: time
2023-07-22 17:16:28 2023-07-22 09:16:28.238 UTC [27] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.301 s, sync=0.002 s, total=0.319 s; sync files=2, longest=0.002 s, average=0.001 s; distance=12 kB, estimate=182 kB
2023-07-22 17:26:27 2023-07-22 09:26:27.402 UTC [27] LOG:  checkpoint starting: time
2023-07-22 17:26:31 2023-07-22 09:26:31.134 UTC [27] LOG:  checkpoint complete: wrote 38 buffers (0.2%); 0 WAL file(s) added, 0 removed, 0 recycled; write=3.711 s, sync=0.007 s, total=3.732 s; sync files=24, longest=0.002 s, average=0.001 s; distance=125 kB, estimate=176 kB
2023-07-22 17:45:25 2023-07-22 09:45:25.716 UTC [1] LOG:  received fast shutdown request
2023-07-22 17:45:25 2023-07-22 09:45:25.720 UTC [1] LOG:  aborting any active transactions
2023-07-22 17:45:25 2023-07-22 09:45:25.722 UTC [1] LOG:  background worker "logical replication launcher" (PID 32) exited with exit code 1
2023-07-22 17:45:25 2023-07-22 09:45:25.725 UTC [27] LOG:  shutting down
2023-07-22 17:45:25 2023-07-22 09:45:25.728 UTC [27] LOG:  checkpoint starting: shutdown immediate
2023-07-22 17:45:25 2023-07-22 09:45:25.736 UTC [27] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.012 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=159 kB
2023-07-22 17:45:25 2023-07-22 09:45:25.742 UTC [1] LOG:  database system is shut down
2023-07-22 17:50:15 2023-07-22 09:50:15.812 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-22 17:50:15 2023-07-22 09:50:15.812 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-22 17:50:15 2023-07-22 09:50:15.813 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-22 17:50:15 2023-07-22 09:50:15.817 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-22 17:50:15 2023-07-22 09:50:15.825 UTC [28] LOG:  database system was shut down at 2023-07-22 09:45:25 UTC
2023-07-22 17:50:15 2023-07-22 09:50:15.842 UTC [1] LOG:  database system is ready to accept connections
2023-07-22 17:50:27 2023-07-22 09:50:27.526 UTC [46] ERROR:  relation "session_session_id_idx" already exists
2023-07-22 17:50:27 2023-07-22 09:50:27.526 UTC [46] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-22 17:50:27 2023-07-22 09:50:27.528 UTC [46] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-22 17:50:27 2023-07-22 09:50:27.528 UTC [46] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-22 17:50:27 2023-07-22 09:50:27.529 UTC [46] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-22 17:50:27 2023-07-22 09:50:27.529 UTC [46] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-22 17:50:27 2023-07-22 09:50:27.530 UTC [46] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-22 17:50:27 2023-07-22 09:50:27.530 UTC [46] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-22 17:55:15 2023-07-22 09:55:15.879 UTC [26] LOG:  checkpoint starting: time
2023-07-22 17:55:16 2023-07-22 09:55:16.008 UTC [26] LOG:  checkpoint complete: wrote 4 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.106 s, sync=0.010 s, total=0.129 s; sync files=3, longest=0.008 s, average=0.004 s; distance=0 kB, estimate=0 kB
2023-07-23 08:21:27 2023-07-23 00:21:27.486 UTC [1] LOG:  received fast shutdown request
2023-07-23 08:21:27 2023-07-23 00:21:27.491 UTC [1] LOG:  aborting any active transactions
2023-07-23 08:21:27 2023-07-23 00:21:27.492 UTC [1] LOG:  background worker "logical replication launcher" (PID 31) exited with exit code 1
2023-07-23 08:21:27 2023-07-23 00:21:27.493 UTC [26] LOG:  shutting down
2023-07-23 08:21:27 2023-07-23 00:21:27.496 UTC [26] LOG:  checkpoint starting: shutdown immediate
2023-07-23 08:21:27 2023-07-23 00:21:27.520 UTC [26] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.027 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-23 08:21:27 2023-07-23 00:21:27.524 UTC [1] LOG:  database system is shut down
2023-07-24 10:09:31 2023-07-24 02:09:31.614 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-24 10:09:31 2023-07-24 02:09:31.614 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-24 10:09:31 2023-07-24 02:09:31.614 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-24 10:09:31 2023-07-24 02:09:31.620 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-24 10:09:31 2023-07-24 02:09:31.627 UTC [29] LOG:  database system was shut down at 2023-07-23 00:21:27 UTC
2023-07-24 10:09:31 2023-07-24 02:09:31.633 UTC [1] LOG:  database system is ready to accept connections
2023-07-24 10:09:42 2023-07-24 02:09:42.338 UTC [47] ERROR:  relation "session_session_id_idx" already exists
2023-07-24 10:09:42 2023-07-24 02:09:42.338 UTC [47] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-24 10:09:42 2023-07-24 02:09:42.339 UTC [47] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-24 10:09:42 2023-07-24 02:09:42.339 UTC [47] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-24 10:09:42 2023-07-24 02:09:42.339 UTC [47] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-24 10:09:42 2023-07-24 02:09:42.339 UTC [47] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-21 17:23:08 running bootstrap script ... ok
2023-07-21 17:23:09 performing post-bootstrap initialization ... ok
2023-07-21 17:23:09 syncing data to disk ... ok
2023-07-21 17:23:09
2023-07-21 17:23:09
2023-07-21 17:23:09 Success. You can now start the database server using:
2023-07-21 17:23:09
2023-07-21 17:23:09     pg_ctl -D /var/lib/postgresql/data -l logfile start
2023-07-21 17:23:09
2023-07-21 17:23:09 waiting for server to start....2023-07-21 09:23:09.392 UTC [49] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-21 17:23:09 2023-07-21 09:23:09.395 UTC [49] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-21 17:23:09 2023-07-21 09:23:09.402 UTC [52] LOG:  database system was shut down at 2023-07-21 09:23:09 UTC
2023-07-21 17:23:09 2023-07-21 09:23:09.408 UTC [49] LOG:  database system is ready to accept connections
2023-07-21 17:23:09  done
2023-07-21 17:23:09 server started
2023-07-21 17:23:09
2023-07-21 17:23:09 /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
2023-07-21 17:23:09
2023-07-21 17:23:09 2023-07-21 09:23:09.558 UTC [49] LOG:  received fast shutdown request
2023-07-21 17:23:09 waiting for server to shut down....2023-07-21 09:23:09.561 UTC [49] LOG:  aborting any active transactions
2023-07-21 17:23:09 2023-07-21 09:23:09.563 UTC [49] LOG:  background worker "logical replication launcher" (PID 55) exited with exit code 1
2023-07-21 17:23:09 2023-07-21 09:23:09.564 UTC [50] LOG:  shutting down
2023-07-21 17:23:09 2023-07-21 09:23:09.566 UTC [50] LOG:  checkpoint starting: shutdown immediate
2023-07-21 17:23:09 2023-07-21 09:23:09.582 UTC [50] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.007 s, sync=0.002 s, total=0.018 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-21 17:23:09 2023-07-21 09:23:09.586 UTC [49] LOG:  database system is shut down
2023-07-21 17:23:09  done
2023-07-21 17:23:09 server stopped
2023-07-21 17:23:09
2023-07-21 17:23:09 PostgreSQL init process complete; ready for start up.
2023-07-21 17:23:09
2023-07-22 15:11:26
2023-07-22 15:11:26 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-22 15:11:26
2023-07-22 17:50:15
2023-07-22 17:50:15 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-22 17:50:15
2023-07-24 10:09:31
2023-07-24 10:09:31 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-24 10:09:31
2023-07-24 14:23:31
2023-07-24 14:23:31 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-24 14:23:31
2023-07-24 10:09:42 2023-07-24 02:09:42.340 UTC [47] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-24 10:09:42 2023-07-24 02:09:42.340 UTC [47] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-24 10:14:31 2023-07-24 02:14:31.726 UTC [27] LOG:  checkpoint starting: time
2023-07-24 10:14:31 2023-07-24 02:14:31.752 UTC [27] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.010 s, sync=0.002 s, total=0.026 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-24 10:58:38 2023-07-24 02:58:38.385 UTC [4182] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.387 UTC [4183] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.390 UTC [4184] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.391 UTC [4185] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.395 UTC [4186] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.896 UTC [4188] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.901 UTC [4189] LOG:  invalid length of startup packet
2023-07-24 10:58:38 2023-07-24 02:58:38.907 UTC [4190] LOG:  invalid length of startup packet
2023-07-24 10:58:39 2023-07-24 02:58:39.968 UTC [4191] LOG:  invalid length of startup packet
2023-07-24 10:58:39 2023-07-24 02:58:39.971 UTC [4192] LOG:  invalid length of startup packet
2023-07-24 10:58:39 2023-07-24 02:58:39.975 UTC [4193] LOG:  invalid length of startup packet
2023-07-24 10:58:40 2023-07-24 02:58:40.431 UTC [4194] LOG:  invalid length of startup packet
2023-07-24 10:58:40 2023-07-24 02:58:40.435 UTC [4195] LOG:  invalid length of startup packet
2023-07-24 10:58:40 2023-07-24 02:58:40.438 UTC [4196] LOG:  invalid length of startup packet
2023-07-24 14:22:42 2023-07-24 06:22:42.860 UTC [1] LOG:  received fast shutdown request
2023-07-24 14:22:42 2023-07-24 06:22:42.867 UTC [1] LOG:  aborting any active transactions
2023-07-24 14:22:42 2023-07-24 06:22:42.869 UTC [1] LOG:  background worker "logical replication launcher" (PID 32) exited with exit code 1
2023-07-24 14:22:42 2023-07-24 06:22:42.869 UTC [27] LOG:  shutting down
2023-07-24 14:22:42 2023-07-24 06:22:42.874 UTC [27] LOG:  checkpoint starting: shutdown immediate
2023-07-24 14:22:42 2023-07-24 06:22:42.890 UTC [27] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.022 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-24 14:22:42 2023-07-24 06:22:42.896 UTC [1] LOG:  database system is shut down
2023-07-24 14:23:31 2023-07-24 06:23:31.160 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-24 14:23:31 2023-07-24 06:23:31.161 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-24 14:23:31 2023-07-24 06:23:31.162 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-24 14:23:31 2023-07-24 06:23:31.169 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-24 14:23:31 2023-07-24 06:23:31.178 UTC [29] LOG:  database system was shut down at 2023-07-24 06:22:42 UTC
2023-07-24 14:23:31 2023-07-24 06:23:31.185 UTC [1] LOG:  database system is ready to accept connections
2023-07-24 14:23:41 2023-07-24 06:23:41.907 UTC [47] ERROR:  relation "session_session_id_idx" already exists
2023-07-24 14:23:41 2023-07-24 06:23:41.907 UTC [47] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-24 14:23:41 2023-07-24 06:23:41.908 UTC [47] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-24 14:23:41 2023-07-24 06:23:41.908 UTC [47] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-24 14:23:41 2023-07-24 06:23:41.909 UTC [47] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-24 14:23:41 2023-07-24 06:23:41.909 UTC [47] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-24 14:23:41 2023-07-24 06:23:41.910 UTC [47] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-24 14:23:41 2023-07-24 06:23:41.910 UTC [47] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-24 14:28:31 2023-07-24 06:28:31.230 UTC [27] LOG:  checkpoint starting: time
2023-07-24 14:28:31 2023-07-24 06:28:31.245 UTC [27] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.005 s, sync=0.002 s, total=0.018 s; sync files=2, longest=0.002 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-24 14:31:31 2023-07-24 06:31:31.986 UTC [1] LOG:  received fast shutdown request
2023-07-24 14:31:31 2023-07-24 06:31:31.989 UTC [1] LOG:  aborting any active transactions
2023-07-24 14:31:31 2023-07-24 06:31:31.991 UTC [1] LOG:  background worker "logical replication launcher" (PID 32) exited with exit code 1
2023-07-24 14:31:31 2023-07-24 06:31:31.991 UTC [27] LOG:  shutting down
2023-07-24 14:31:31 2023-07-24 06:31:31.994 UTC [27] LOG:  checkpoint starting: shutdown immediate
2023-07-24 14:31:32 2023-07-24 06:31:32.006 UTC [27] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.015 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-24 14:31:35
2023-07-24 14:31:35 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-24 14:31:35
2023-07-24 14:31:32 2023-07-24 06:31:32.010 UTC [1] LOG:  database system is shut down
2023-07-24 14:31:35 2023-07-24 06:31:35.358 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-24 14:31:35 2023-07-24 06:31:35.358 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-24 14:31:35 2023-07-24 06:31:35.358 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-24 14:31:35 2023-07-24 06:31:35.362 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-24 14:31:35 2023-07-24 06:31:35.370 UTC [28] LOG:  database system was shut down at 2023-07-24 06:31:32 UTC
2023-07-24 14:31:35 2023-07-24 06:31:35.383 UTC [1] LOG:  database system is ready to accept connections
2023-07-24 14:31:46 2023-07-24 06:31:46.057 UTC [46] ERROR:  relation "session_session_id_idx" already exists
2023-07-24 14:31:46 2023-07-24 06:31:46.057 UTC [46] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-24 14:31:46 2023-07-24 06:31:46.058 UTC [46] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-24 14:31:46 2023-07-24 06:31:46.058 UTC [46] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-24 14:31:46 2023-07-24 06:31:46.059 UTC [46] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-24 14:31:46 2023-07-24 06:31:46.059 UTC [46] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-24 14:31:46 2023-07-24 06:31:46.060 UTC [46] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-24 14:31:46 2023-07-24 06:31:46.060 UTC [46] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-24 14:36:35 2023-07-24 06:36:35.465 UTC [26] LOG:  checkpoint starting: time
2023-07-24 14:36:35 2023-07-24 06:36:35.484 UTC [26] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.004 s, sync=0.002 s, total=0.020 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-24 17:45:15 2023-07-24 09:45:15.598 UTC [1] LOG:  received fast shutdown request
2023-07-24 17:45:15 2023-07-24 09:45:15.604 UTC [1] LOG:  aborting any active transactions
2023-07-24 17:45:15 2023-07-24 09:45:15.605 UTC [1] LOG:  background worker "logical replication launcher" (PID 31) exited with exit code 1
2023-07-24 17:45:15 2023-07-24 09:45:15.606 UTC [26] LOG:  shutting down
2023-07-24 17:45:15 2023-07-24 09:45:15.610 UTC [26] LOG:  checkpoint starting: shutdown immediate
2023-07-24 17:45:15 2023-07-24 09:45:15.623 UTC [26] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.017 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-24 17:45:15 2023-07-24 09:45:15.627 UTC [1] LOG:  database system is shut down
2023-07-25 08:27:39 2023-07-25 00:27:39.122 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-25 08:27:39 2023-07-25 00:27:39.123 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-25 08:27:39 2023-07-25 00:27:39.123 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-25 08:27:39 2023-07-25 00:27:39.128 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-25 08:27:39 2023-07-25 00:27:39.136 UTC [29] LOG:  database system was shut down at 2023-07-24 09:45:15 UTC
2023-07-25 08:27:39 2023-07-25 00:27:39.144 UTC [1] LOG:  database system is ready to accept connections
2023-07-25 08:27:49 2023-07-25 00:27:49.819 UTC [47] ERROR:  relation "session_session_id_idx" already exists
2023-07-25 08:27:49 2023-07-25 00:27:49.819 UTC [47] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-25 08:27:49 2023-07-25 00:27:49.820 UTC [47] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-25 08:27:49 2023-07-25 00:27:49.820 UTC [47] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-25 08:27:49 2023-07-25 00:27:49.822 UTC [47] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-25 08:27:49 2023-07-25 00:27:49.822 UTC [47] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-25 08:27:49 2023-07-25 00:27:49.823 UTC [47] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-25 08:27:49 2023-07-25 00:27:49.823 UTC [47] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-25 08:32:39 2023-07-25 00:32:39.236 UTC [27] LOG:  checkpoint starting: time
2023-07-25 08:32:39 2023-07-25 00:32:39.256 UTC [27] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.004 s, sync=0.002 s, total=0.021 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-25 08:45:37 2023-07-25 00:45:37.665 UTC [1546] LOG:  could not send data to client: Broken pipe
2023-07-25 08:45:37 2023-07-25 00:45:37.668 UTC [1546] FATAL:  connection to client lost
2023-07-25 09:45:28 2023-07-25 01:45:28.053 UTC [1] LOG:  received fast shutdown request
2023-07-25 08:27:39
2023-07-25 08:27:39 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-25 08:27:39
2023-07-25 10:02:56
2023-07-25 10:02:56 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-25 10:02:56
2023-07-25 14:22:40
2023-07-25 14:22:40 PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-07-25 14:22:40
2023-07-25 09:45:28 2023-07-25 01:45:28.063 UTC [1] LOG:  aborting any active transactions
2023-07-25 09:45:28 2023-07-25 01:45:28.065 UTC [1] LOG:  background worker "logical replication launcher" (PID 32) exited with exit code 1
2023-07-25 09:45:28 2023-07-25 01:45:28.065 UTC [27] LOG:  shutting down
2023-07-25 09:45:28 2023-07-25 01:45:28.071 UTC [27] LOG:  checkpoint starting: shutdown immediate
2023-07-25 09:45:28 2023-07-25 01:45:28.093 UTC [27] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.028 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-25 09:45:28 2023-07-25 01:45:28.099 UTC [1] LOG:  database system is shut down
2023-07-25 10:02:56 2023-07-25 02:02:56.952 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-25 10:02:56 2023-07-25 02:02:56.952 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-25 10:02:56 2023-07-25 02:02:56.952 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-25 10:02:56 2023-07-25 02:02:56.958 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-25 10:02:56 2023-07-25 02:02:56.966 UTC [30] LOG:  database system was shut down at 2023-07-25 01:45:28 UTC
2023-07-25 10:02:56 2023-07-25 02:02:56.972 UTC [1] LOG:  database system is ready to accept connections
2023-07-25 10:03:07 2023-07-25 02:03:07.582 UTC [48] ERROR:  relation "session_session_id_idx" already exists
2023-07-25 10:03:07 2023-07-25 02:03:07.582 UTC [48] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-25 10:03:07 2023-07-25 02:03:07.584 UTC [48] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-25 10:03:07 2023-07-25 02:03:07.584 UTC [48] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-25 10:03:07 2023-07-25 02:03:07.585 UTC [48] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-25 10:03:07 2023-07-25 02:03:07.585 UTC [48] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-25 10:03:07 2023-07-25 02:03:07.586 UTC [48] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-25 10:03:07 2023-07-25 02:03:07.586 UTC [48] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-25 10:07:56 2023-07-25 02:07:56.990 UTC [28] LOG:  checkpoint starting: time
2023-07-25 10:07:57 2023-07-25 02:07:57.009 UTC [28] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.004 s, sync=0.002 s, total=0.020 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-25 14:19:17 2023-07-25 06:19:17.369 UTC [1] LOG:  received fast shutdown request
2023-07-25 14:19:17 2023-07-25 06:19:17.374 UTC [1] LOG:  aborting any active transactions
2023-07-25 14:19:17 2023-07-25 06:19:17.375 UTC [1] LOG:  background worker "logical replication launcher" (PID 33) exited with exit code 1
2023-07-25 14:19:17 2023-07-25 06:19:17.377 UTC [28] LOG:  shutting down
2023-07-25 14:19:17 2023-07-25 06:19:17.381 UTC [28] LOG:  checkpoint starting: shutdown immediate
2023-07-25 14:19:17 2023-07-25 06:19:17.398 UTC [28] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.022 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-25 14:19:17 2023-07-25 06:19:17.403 UTC [1] LOG:  database system is shut down
2023-07-25 14:22:41 2023-07-25 06:22:41.031 UTC [1] LOG:  starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-07-25 14:22:41 2023-07-25 06:22:41.031 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2023-07-25 14:22:41 2023-07-25 06:22:41.031 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2023-07-25 14:22:41 2023-07-25 06:22:41.037 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-07-25 14:22:41 2023-07-25 06:22:41.045 UTC [29] LOG:  database system was shut down at 2023-07-25 06:19:17 UTC
2023-07-25 14:22:41 2023-07-25 06:22:41.052 UTC [1] LOG:  database system is ready to accept connections
2023-07-25 14:22:51 2023-07-25 06:22:51.191 UTC [47] ERROR:  relation "session_session_id_idx" already exists
2023-07-25 14:22:51 2023-07-25 06:22:51.191 UTC [47] STATEMENT:  CREATE INDEX "session_session_id_idx" ON "session" ("session_id")
2023-07-25 14:22:51 2023-07-25 06:22:51.192 UTC [47] ERROR:  relation "memstore_session_id_idx" already exists
2023-07-25 14:22:51 2023-07-25 06:22:51.192 UTC [47] STATEMENT:  CREATE INDEX "memstore_session_id_idx" ON "message" ("session_id")
2023-07-25 14:22:51 2023-07-25 06:22:51.193 UTC [47] ERROR:  relation "sumstore_session_id_idx" already exists
2023-07-25 14:22:51 2023-07-25 06:22:51.193 UTC [47] STATEMENT:  CREATE INDEX "sumstore_session_id_idx" ON "summary" ("session_id")
2023-07-25 14:22:51 2023-07-25 06:22:51.194 UTC [47] ERROR:  relation "mem_vec_store_session_id_idx" already exists
2023-07-25 14:22:51 2023-07-25 06:22:51.194 UTC [47] STATEMENT:  CREATE INDEX "mem_vec_store_session_id_idx" ON "message_embedding" ("session_id")
2023-07-25 14:27:41 2023-07-25 06:27:41.147 UTC [27] LOG:  checkpoint starting: time
2023-07-25 14:27:41 2023-07-25 06:27:41.167 UTC [27] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.004 s, sync=0.002 s, total=0.021 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB
2023-07-25 14:50:59 2023-07-25 06:50:59.279 UTC [1] LOG:  received fast shutdown request
2023-07-25 14:50:59 2023-07-25 06:50:59.282 UTC [1] LOG:  aborting any active transactions
2023-07-25 14:50:59 2023-07-25 06:50:59.284 UTC [1] LOG:  background worker "logical replication launcher" (PID 32) exited with exit code 1
2023-07-25 14:50:59 2023-07-25 06:50:59.285 UTC [27] LOG:  shutting down
2023-07-25 14:50:59 2023-07-25 06:50:59.287 UTC [27] LOG:  checkpoint starting: shutdown immediate
2023-07-25 14:50:59 2023-07-25 06:50:59.295 UTC [27] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.011 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB
2023-07-25 14:50:59 2023-07-25 06:50:59.300 UTC [1] LOG:  database system is shut down

I would be happy to add any areas that may have been missed 0v0

I don't see client requests in the Zep logs. Can you confirm that you've using the correct URL and port when you configure the Zep client?
You should see entries similar to this in your Zep logs if there are successful requests:
INFO[2023-07-25T20:23:30-07:00] http://YOURHOST:8000/api/v1/XXXX       bytes=283 category=router duration=5853083 duration_display=5.853291ms method=GET proto=HTTP/1.1 remote_ip=<IP_ADDRESS> status_code=200

I don't see client requests in the Zep logs. Can you confirm that you've using the correct URL and port when you configure the Zep client?
You should see entries similar to this in your Zep logs if there are successful requests:
INFO[2023-07-25T20:23:30-07:00] https://YOURHOST:8000/api/v1/XXXX       bytes=283 category=router duration=5853083 duration_display=5.853291ms method=GET proto=HTTP/1.1 remote_ip=<IP_ADDRESS> status_code=200

I'm using zep deployed by docker, the default url is "http://localhost:8000", and I also tried "http://localhost:8080", but again nothing happens, and there is no record of link failure even on the server side

Do you have any other services running on your PC that may be listening on port 8000? My guess is that something else is intercepting requests to Zep.

@jkgdz Would you please update the zep-python client to v0.34? This new version includes a test to determine whether the client can successfully connect to the Zep server.

Well, okay, I'm sorry I haven't seen any response messages from Github in the past few days

It seems useless. My code uses langchain code, and there is no call to zep-python in the code. However, thank you for being willing to help me 0v0

@jkgdz The Langchain ZepMemory and ZepRetriever classes call the Zep Python SDK. Please reopen this issue if you have the opportunity to upgrade the Zep Python package and still need assistance.


Fix links to RobCoGen in the readme

Hi Markus (?) !
I just fixed the links to robcogen in the readme.
It would be nice if the CT home page has the right links :)

No idea why github actions refuses to run the tests. Will look into it later.


more basic unit tests

Hi,
the parse() test, https://github.com/sbcgua/ajson/blob/master/src/zcl_ajson.clas.testclasses.abap#L122 seems to be testing a lot?
Are you open to adding more basic unit tests before this? eg. one test method for each data type

generally yes, this is better. I'm just lazy to do one-by-one :) And I reuse that mock json a couple of times so it saves time. But conceptually this is better to have separate tests.
Just one thing, this test tests types, and also depth. (Althought there is an integrational one somewhere there ...)

generally yes, this is better. I'm just lazy to do one-by-one :) And I reuse that mock json a couple of times so it saves time. But conceptually this is better to have separate tests.
Just one thing, this test tests types, and also depth. (Althought there is an integrational one somewhere there ...)

I'll just add more, more is more

I'll just add more, more is more

merged, closing


Fix letter 's' in banner

Resolve #106

:tada: This PR is included in version 1.7.0 :tada:
The release is available on:

npm package (@latest dist-tag)
Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


Move to the codeql-testing org

Refer to the pack variants in codeql-testing, not in dsp-testing.

Hm... looks like we have an authentication problem?
      A fatal error occurred: Error getting package versions 'codeql-testing/codeql-pack1' to the public GitHub Container registry: HTTP/1.1 403 Forbidden. Response body: '{"errors":[{"code":"DENIED","message":"permission_denied: read_package"}]}
' Do you need to specify a token to authenticate to the registry?

I know exactly what the problem is. I just need to update some permissions on the test packs.


Do you support Telelyne Dalsa Ginie Nano c1930

I am using c1930 Telelyne Dalsa Ginie Nano c1930
Installed SDK, harvester and harvester-gui
`from harvesters.core import Harvester
h = Harvester()
ATTENTION! Please use the CTI file in the original location!
Why? Visit https://github.com/genicam/harvesters/wiki/FAQ and
read "I pointed out a CTI file but Harvester says the image doesn't
exist (Part 2)."
h.add_cti_file("C:\ProgramData\Anaconda3\Lib\site-packages\genicam2\TLSimu.cti")
print(h.cti_files)
h.update_device_info_list()
print(h.device_info_list)
`
Output

Kindly help.

Hi. Perhaps something could be wrong but note that TLSimu is just a simulator that is used to test Harvester. You can't control your Ginie though it. Please get an apropriate GenTL Prodcuer first and make a try. Thanks. -Kazunari

@kazunarikudo Kindly help me to find the proper GentTL producer, I am unable to find the same.
Kindly tell me if Harvester is already tested on Teledyne Dalsa Ginie Nano Models.

You may want to take a look at this page. I have ever been consulted by a guy who wanted to use a Ginie so you should also be able to use that.

I can confirm that GenieNano M2420 works with harvesters and Matrix Vision producer in ubuntu 18.04.


Change to a more appropriate license

You have chosen to release this code using an MIT License. The license reads, in part:

"Permission is hereby granted, free of charge, to any person obtaining a copy of this software ... to deal in the Software without restriction, including without limitation the rights to ... sublicense and/or sell copies of the Software."

But then you also write in the README:

"I don't care if you copy the source code to use in your project, but please avoid simply changing the name and selling as your work without further change. That's not why I'm sharing the source code, at all."

That request is contrary to the terms of the license. You can't offer the code under a license with a set of terms, then tell people you don't want them  to follow those terms.
If you do not want people to sell the code, please choose a different license. You may want to consider a CC-BY-NC license if you don't want someone to sell it. I'm not aware of any standard license, however, that prohibits someone from forking and renaming a project, without making changes.

Hi,
Thanks for sharing this. I understand the confusion. Here is why I did this:

I'm OK if people want to use this app for commercial use.
I'm OK if people clone or fork this app. Also, I figured that a lot of people fork repositories to bookmark them instead of "star" them.
I'm OK if people fork the project, make significant changes (add features, change the behavior deeply, change the UI deeply) and then sell it under a different name.
What I'm not OK with is when people fork the project, change the name and icon and nothing else (so no added value from the original repo), and sell it.

Ultimately, I'd like to avoid a scenario like Captura: https://github.com/MathewSachin/Captura/issues/405#issuecomment-657065501
Unfortunately, I don't know any license that would prevent this.
What do you think about? Any idea of how we could change the license with respect of the above? Perhaps we should write a custom license? I think one of the challenges here is to define what is a significant change.
Thanks :)

Hi,
Thanks for sharing this. I understand the confusion. Here is why I did this:

I'm OK if people want to use this app for commercial use.
I'm OK if people clone or fork this app. Also, I figured that a lot of people fork repositories to bookmark them instead of "star" them.
I'm OK if people fork the project, make significant changes (add features, change the behavior deeply, change the UI deeply) and then sell it under a different name.
What I'm not OK with is when people fork the project, change the name and icon and nothing else (so no added value from the original repo), and sell it.

Ultimately, I'd like to avoid a scenario like Captura: https://github.com/MathewSachin/Captura/issues/405#issuecomment-657065501
Unfortunately, I don't know any license that would prevent this.
What do you think about? Any idea of how we could change the license with respect of the above? Perhaps we should write a custom license? I think one of the challenges here is to define what is a significant change.
Thanks :)

Indeed, you're right. There is no OSI-approved license that would meet those conditions. There are some non-commercial licenses that would prevent someone from selling the code, but nothing that limits it to only forks where nothing is changed.
I think you really have two choices. One would be to create a custom license, that includes these terms. There are some drawbacks to this. Your license would no longer be recognized by GitHub, and it would no longer conform to an OSI-approved license, which could hinder its discovery and adoption in some places. Also, it would only apply to versions of code to which the new license is applied -- all the older versions can't be retroactively changed, so a really committed person could just fork the older version and re-release. (They would not be able to backport changes made after the license change, though, since those changes are bound by the new license terms.)
The other alternative is to change it from a requirement to a recommendation. I think it would perfectly reasonable to say "I'm using a license that permits redistribution and commercial use without changes, but I would really prefer you not, and if you believe you have a strong reason to do so, kindly reach out to discuss with me first." The problem is that you can't legally enforce these restrictions with an MIT license (and it's even harder still to enforce a concept of "added value" - does obfuscating the code without making any changes provided added value?) But changing the wording gives you a chance to outline your concerns without appearing to contradict the license, and may even give you an opportunity to relicense the code for other purposes should the need arise.

Hi @kswartz26 ,
These are great ideas, thank you for sharing!
After chatting with @btiteux , we believe your 2nd option might fit better for us.
I updated the README in the following PR: https://github.com/veler/DevToys/pull/133
Can you please let us know what you think about it?
Thank you so much for your help with this! We really appreciate :)

I think that looks great, and definitely resolves the conflict. Very glad this was helpful to you!

Thank you very much! :D I will merge this change then.


chore: regroup common public nginx-ingresses values

@lemeurherve can you rebase this branch and fix the conflicts?

@dduportal done


⚠ Bofrost.be has degraded performance

In 83d028e, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 910 ms

Resolved: Bofrost.be performance has improved in 8abbaee.


Added svg arrows to Pagination

Added SVG icons to Previous and Next

Another things you have to update your repo it`s out of date


docs(Breadcrumb): refactor and use index.js

Current coverage is 100% (diff: 100%)

Merging #671 into master will not change coverage

@@           master   #671   diff @@
====================================
  Files         132    132
  Lines        2102   2102
  Methods         0      0
  Messages        0      0
  Branches        0      0
====================================
  Hits         2102   2102
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update 24ddc3c...5fbb96f

Thanks much!


Fix issue with shape #14

Would be really cool to see this merged. I just implemented the same thing based on current Flutter AppBar code (before I discovered this PR 😄 ) and it build just fine. I created a gist in case you're interested https://gist.github.com/leontappe/123445ff7e4b4ceb1795fd043c5351ef


Fix video player

Issue #, if available:
The js lib for video player does not work.
Description of changes:

I changed the css and js lib required by the video player.
Minor change: fix the CF output for WAF Rule Group Arn

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Issue was fixed in v1.1.3


Hwo to get log probablity of input tokens?

Confirm this is a feature request for the Python library and not the underlying OpenAI API.

[X] This is a feature request for the Python library

Describe the feature or improvement you're requesting
For a complete context:
Q:Where is Beijing? A:china
I want to get the log_probs of china, how can I do this?
Additional context
No response

Hey @BUAADreamer  - you can follow the guide here on how to use logprobs: https://cookbook.openai.com/examples/using_logprobs#1-using-logprobs-to-assess-confidence-for-classification-tasks
The example presented in this article is quite similar to your use case.

I see, but what I want is the prob of tokens appeared in this history but not new generated tokens

Hmm are you saying that you want probabilities for tokens that you passed to the model as input? That is not supported - the model can only give you probabilities for its own predictions.

Thanks! However, I found REPLUG, a great RAG work, use similar methods to obtain token probs, you can find here:
https://github.com/swj0419/REPLUG/blob/6cbe7971a9b761c63aa65f7fe70db3ee82158612/LSR_finetune/replug_lsr.py#L185
But this is used for get GPT-3 or CodeX output, so this way is now invalid? If yes, will you reopen this usage in the future?

Ah interesting. Yes you would not be able to plug some of the newer models (4o, 4-turbo, 3.5-turbo) into this library because the legacy completions API used here is not compatible with those models. We do not plan to add support for these models to the legacy completions API.
I can see how the feature implemented in this library could be useful, but it's a bit out of our wheelhouse of the maintainers of this GitHub repo, which is just a Python wrapper around the OpenAI API. We can answer questions about and resolve problems with the Python SDK, but I'm afraid I can't comment particularly intelligently on functionality that was implemented as part of a third party library.

Thanks for such a complete  and quick answer!


fix typo

Coverage remained the same at 38.721% when pulling 3f358e7cfdf3c6d5cc480747524ca987d9505ac2 on myarjunar:signin-typo into a97af7592ec3eba653d908072634e095a3ae71c1 on healthsites:develop.


Do not keep asset file open

Closing the file can allow external users to keep track of when GFXR is done updating the file and therefore is safe to access it.

CI gfxreconstruct build queued with queue ID 293303.

CI gfxreconstruct build # 5276 running.

CI gfxreconstruct build # 5276 failed.

CI gfxreconstruct build queued with queue ID 293376.

CI gfxreconstruct build # 5277 running.

CI gfxreconstruct build # 5277 passed.

CI gfxreconstruct build queued with queue ID 296549.

CI gfxreconstruct build queued with queue ID 296563.

CI gfxreconstruct build # 5304 running.

CI gfxreconstruct build # 5304 passed.


[CodeCompletion] Complete Swift only module name after 'import'

For each ModuleLoader, newly implement collectVisibleTopLevelModuleNames() which collects visible module names. It doesn't care about the actual content of the file though. So it doesn't guarantee the module is loadable.
rdar://problem/39392446

@swift-ci Please smoke test

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 3f3ff69e79c2b4ce3539eb4f21b6e72e13e4381a

Build failed
Swift Test Linux Platform
Git Sha - 3f3ff69e79c2b4ce3539eb4f21b6e72e13e4381a

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 3b099bbc8d766f8d41eb800931737ba24c1d64ba

Build failed
Swift Test OS X Platform
Git Sha - 3b099bbc8d766f8d41eb800931737ba24c1d64ba

Initial reaction is that I like the module loading refactoring quite a bit, but I'll need to study it more to see if it preserves behavior.

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

*sigh* I think the tri-state Optional<bool> ended up causing rdar://problem/50789839. I'll probably go through and replace it all with an enum.

@jrose-apple Could you elaborate? Did I make a mistake?

I'm not sure. This morning I'm thinking about it more and I think you didn't make a mistake, but I'm still taking this as evidence that the code isn't as easy-to-read as it could be.

(The issue is that ParseableInterfaceModuleLoader is failing but the compilation process overall is "succeeding", i.e. exiting with an exit code of 0.)


Rename setting

This PR renames the CREATE_UNKNOWN_USERS setting to COGNITO_CREATE_UNKNOWN_USERS so that all Cognito Django settings begin with the COGNITO_ prefix.
This PR looks like I changed a lot of lines because my editor cleans up all trailing whitespace on save.

I'm assigning this one to @ebpetway since he wrote the bulk of the Django backend.


How important is learning vanlliaJS and JS basics?

hi. i had straight up learn with typescript & angular framework(frontend). but i had skipped the basic js thing, i have no idea to build app with vanillaJS, all i know are just angular, NPM & typescript things. is it necessary to learn javascript basics & vanillaJS?

The reason I started the vanillaJS course before teaching React is that I feel it's extremely important. There are multiple reasons to it:

You get better at programming
There's a whole bunch of people who work on creating libraries only.
You are not bound to one framework
Many libraries like Bootstrap are replacing jQuery with vanilla JS
Important for interview
You understand JS better and thus the inner workings of any framework
Sometimes you don't need the bloat of a framework for smaller apps. Makes things faster.
Right your own framework.

I'll explain these points in a video. Watch out Youtube for that.


update README.md, fix when running demo in ios, video will be frozen

In ios 14.2. When running the demo using Safari + IPhone, user cant see the video running normally. And cant use model.predict()
Thx for @derm1ch1, I used his idea.

@Irene Alvarado
@Kyle Phillips
@Jonas Jongejan
Some checks were not successfu
Needs /gcbrun from a collaborator
Can anyone help me to solve this problem?

Some checks were not successfu
Needs /gcbrun from a collaborator
Can anyone help me to solve this problem?
@GautamBose
@HalfdanJ
@irealva

@GautamBose
@HalfdanJ
@irealva
please merge.


Add separate external Halt to etcdraft.Chain

Type of change

New feature

Description
Stops a chain but does not call the haltCallback function, which is used to transfer responsibility to a follower or
inactive chain. This will be used by the channel participation API when removing a channel.
Related issues
FAB-18069

This approach looks good.

I'd like to note for the record, that this control flow still seems very awkward to me. The registrar is calling into the consenter, which as it halts is calling back into the registrar. Any time we have bidirectional binding like this is a red flag in my opinion.
I'd much rather see this implemented in one of two ways:

Leave the internal run state management to the consenter plugins as is done today, and expose a channel or similar mechanism to allow the the registrar to detect when the consenter has exited.
Remove the 'start' / 'halt' bits of the consenter API, and instead require that the caller inject a go routine, and simply have control flow return once the consenter exits, indicating that a shutdown occurred.

I think (2) is probably easier to read and more natural, while (1) is less of an API change and less code. In either case, I think both are better options than an opaque "I'm stopping" callback.

Sorry for the delayed response here. Opened https://jira.hyperledger.org/browse/FAB-18152 to address this.


Add the ability to add a "chain" to an existing matcher

Subject of the issue
This is a feature request. I think it could be a good idea to let people "extend" RSpec matchers with chaining capabilities.
For exammple:
RSpec::Matchers.define_chain BuiltIn::HaveAttributes do
   chain :with_value do |actual_hash|
    expected.value == actual_hash.value
  end
end

it { expect(hash).to have_key(:id).with_value(42) }

We don't really encourage people to monkey patch or inherit from our matchers, they are not even encouraged to know the class names (by which I mean they are tagged as @api private). Depending on this was implemented it could open us up to issues where by people can accidentally make breaking changes to our api which affects how other libraries use our matchers.
So if we were going to do this, I'd really want to lookup other matchers by name, and not by the class; and I'd want the DSL to take the class and create a new one from it, apply the block and override the old implementation.
So it would look more like:
RSpec::Matchers.extend_existing :have_attributes do
   chain :with_value do |actual_hash|
    expected.value == actual_hash.value
  end
end

it { expect(hash).to have_attribute(:id).with_value(42) }

But even this still risks breaking implementations that also rely on names...

Thanks Jon for your answer. After everything you say, it seems to be a bad idea :)
Feel free to close this feature request if you think we should not accept a proposal for this.😉

If you want to investigate this further I don't mind, if you want to close I don't mind, I just wanted to point out the potential pitfalls :)

Ok. I will let the feature request as open. If no one request it, I will close it before RSpec 4. :)

Please correct me if I'm mistaken, but I'm under the impression this can be done with something like:
module HaveAttributesWithValue
  def with_value(value)
    @expected_value = value
  end

  def matches?(actual)
    super && @expected_value == actual_hash.value
  end
end

BuiltIn::HaveAttributes.prepend(HaveAttributesWithValue)

# or even better

module RSpec
  module Matchers
    class HaveAttributesEx < BuiltIn::HaveAttributes
      prepend HaveAttributesWithValue
    end

    def have_key(expected)
      HaveAttributesEx.new(expected)
    end
  end
end

it { expect(hash).to have_key(:id).with_value(42) }

The first is no better/worse than @benoittgt's ideas, the second overrides our implementation and would have the same problems with other uses, but at least it would be deliberate by the user.

the second overrides our implementation

Does it?

Does it?
It does if we define have_key

It can probably overlap with our have_* predicate matchers. However, this is just an example of adding a chainable specifier to an arbitrary matcher. Not necessary to a built-in RSpec matcher.
This technique allows both to extend an existing matcher, or to extend in a subclass without affecting an existing matcher.
Also, this doesn't have to be defined in RSpec::Matchers namespace at all. Can be in a user namespace, and included in example groups that need this matcher. I've used RSpec::Matchers for simplicity since it's included by default.

This technique allows both to extend an existing matcher, or to extend in a subclass without affecting an existing matcher.

This is my point, it doesn't prevent affecting an existing matcher when it overrides how that matcher is used. Remember people use the matcher names to access matchers, not the classes...

I'm sure I quite understand why you are so opposed to this technique?
Doesn't
RSpec::Matchers.define_chain BuiltIn::HaveAttributes do
   chain :with_value do |actual_hash|
    expected.value == actual_hash.value
  end
end

affect an existing matcher in the same way?
The reason I'm proposing it is that there's (probably) nothing needs to be done, and there's nothing to maintain except for adding documentation for how to do this. As opposed to define_chain will be a new feature.

I'm sure I quite understand why you are so opposed to this technique? Doesn't  affect an existing matcher in the same way?

I'm not opposed to it, I'm just saying it has similar drawbacks to the other suggested implementations, so yes  does affect existing matchers in the same way.

The reason I'm proposing it is that there's (probably) nothing needs to be done, and there's nothing to maintain except for adding documentation for how to do this. As opposed to define_chain will be a new feature.

Remember that classes are not a public API for our matchers, your proposed solution would still require us to make changes to our support, I'm not convinced we need to allow this personally I'm just open to @benoittgt researching it more :)

Closing due to inactivity during the monorepo migration


Unhealthy services

Hi, I have a fresh build of Xpresso in my lab running on VM with 12 vCPUs, 32GB RAM, and 300GB storage and have two unhealthy services- xpresso_jenkinsengine-celery_1 and xpresso_users-celery_1. I've checked the docker logs for both services and don't see anything that jumps out, the only real complaint is that I'm running the worker with elevated privileges.
Thanks...

Hi Rick, I can see that you are a Cisco employee.
This means you have access to piestack. You can use it to raise Xpresso related issues.
Make sure you provide as many details as possible so we can better assist you

Thank you Douglas, how do I access piestack?
.:|:.:|:. Rick Bauer, CCDE #2014::8, CCIE #9482, DEVNET Professional
Technical Solutions Architect | Cisco Systems, Inc.
Enterprise Networking Campus Automation Center of Excellence
SNR: +1<PHONE_NUMBER> |<EMAIL_ADDRESS>From: Douglas Monteiro @.>
Date: Monday, April 4, 2022 at 10:41 AM
To: CiscoTestAutomation/xpresso @.>
Cc: Rick Bauer (rickbaue) @.>, Author @.>
Subject: Re: [CiscoTestAutomation/xpresso] Unhealthy services (Issue #44)
Hi Rick, I can see that you are a Cisco employee.
This means you have access to piestack. You can use it to raise Xpresso related issues.
Make sure you provide as many details as possible so we can better assist you
—
Reply to this email directly, view it on GitHubhttps://github.com/CiscoTestAutomation/xpresso/issues/44#issuecomment-1087642253, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEWMKLDFHFQF3ZJCWBMP4HDVDL5JDANCNFSM5SIRPTBQ.
You are receiving this because you authored the thread.Message ID: @.***>

Thank you.
.:|:.:|:. Rick Bauer, CCDE #2014::8, CCIE #9482, DEVNET Professional
Technical Solutions Architect | Cisco Systems, Inc.
Enterprise Networking Campus Automation Center of Excellence
SNR: +1<PHONE_NUMBER> |<EMAIL_ADDRESS>From: Douglas Monteiro @.>
Date: Wednesday, April 6, 2022 at 10:08 AM
To: CiscoTestAutomation/xpresso @.>
Cc: Rick Bauer (rickbaue) @.>, Author @.>
Subject: Re: [CiscoTestAutomation/xpresso] Unhealthy services (Issue #44)
Hi Rick,
Here is the url: http://piestack.cisco.com/
—
Reply to this email directly, view it on GitHubhttps://github.com/CiscoTestAutomation/xpresso/issues/44#issuecomment-1090317056, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEWMKLGQID5RFTTXI2RD4P3VDWLHBANCNFSM5SIRPTBQ.
You are receiving this because you authored the thread.Message ID: @.***>

Great. I will close the issue, but please open a ticket on piestack whenever you're ready.


Ability to override log levels for contributions

What kind of change does this PR introduce? (check one with "x")
[] Bugfix
[x] Feature
[] Code style update (formatting, local variables)
[] Refactoring (no functional changes, no api changes)
[] Other... Please describe:

Fixes: #
What is the current behavior?
Currently, app developers can not set different log level for contributions. Today, engine log level controls log levels for all contributions. For debug log level, app developers end up seeing unnecessary logs from the engine and other contributions.
What is the new behavior?
With this change, developers can set different log level for contributions(activity/trigger) through below environment variable.
FLOGO_CONTRIB_LOG_LEVEL_OVERRIDE="<CONTRIB_LOGGER_MATCHER>=<LOG_LEVEL>,<CONTRIB_LOGGER_MATCHER>=<LOG_LEVEL>"
e.g. To enable debug logs for Rest activity, set FLOGO_CONTRIB_LOG_LEVEL_OVERRIDE="activity-rest=DEBUG"
To enable debug logs for Rest activity and trigger, set FLOGO_CONTRIB_LOG_LEVEL_OVERRIDE="rest=DEBUG"

Nice to have feature.  sometimes it is useful to debug a big flogo.json

I think the problem is that we have "application" level debug logging and then developer elvel "debug" logging.   Should we distinguish those.. or have a best practices.. maybe add a TRACE level or something?

Hmm, so as an app developer I need to remember that not only there is an app level but also a separate extension level debug setting 🤔 that’s gonna make my life as a developer more difficult, to be honest. I agree with Frank that a TRACE level might be better here.

I agree with @retgits & @fm-tibco I don't think this is the right approach to the problem we're trying to solve.

I think having DEBUG & TRACE and a best practices on when to use which would probably alleviate this issue a bit.  I know that the log currently gets overwhelmed with debug statements that are just helpful to developers

@vijaynalawade does the problem have an issue associated with it? Want to make sure we clearly capture the problem we're trying to solve...

@mellistibco: Today debug logs are really overwhelming and with more number of contributions used in the given app, they can get more and more difficult to read. The idea here is to just let developers (app or contrib) quickly set different log level for certain contributions than the engine. With many contributions in single app,  I dont think TRACE level logging would help either.

While I'd disagree with that, I also believe that we should have an open discussion so we can explore the arguments on both ends.
Why is it difficult to read? Is it the sheer number of messages on the screen, or does it have to do with the ability to find certain data points? Assuming that in a production environment the logs would go to a system like Splunk, this would only be for development purposes. So we could make the logs more readable by adding color to statements (the word error could be red, a warning could be yellow and so on). That would give you a visual indication of what to look for.
I personally think the TRACE option is a better idea because a lot of the statements I see in the DEBUG log today are most likely more TRACE statements. I'm guessing the functionality is inspired by Log4J and looking at their definitions of those two levels:

The DEBUG Level designates fine-grained informational events that are most useful to debug an application.
the TRACE Level designates finer-grained informational events than the DEBUG

Something like printing mapping statements that we execute might in that case actually be more of a TRACE than a DEBUG statement (and yes, I fully realize I've created PRs in the past that output debug logs where, in hindsight, a trace would have been a better option).
Educating users of a library or product is one of the most difficult things to do and I fundamentally believe that we should most certainly think about the user impact and benefits and how we help the user understand this new setting. Parts of our documentation is off-the-charts good, but other parts (like some of our settings) deserve a lot more attention.


On aarch64 architecture. 'tokio-runtime-worker' panicked. The feature 'websocket' is not compiled in this binary.

rathole v0.5.0
Describe the bug

Run: RUST_BACKTRACE=1 rathole /etc/rathole/config.toml
thread 'tokio-runtime-worker' panicked at 'The feature 'websocket' is not compiled in this binary. Please re-compile rathole'
To Reproduce
Steps to reproduce the behavior:

RUST_BACKTRACE=1 rathole /etc/rathole/config.toml

Configuration
Configuration used to reproduce the behavior:
[client]
remote_addr = "<IP_ADDRESS>:5000"
default_token = "456123"
[client.transport]
type = "websocket"
[client.transport.websocket]
tls = false
[client.services.pwg]
type = "udp"
local_addr = "<IP_ADDRESS>:1838"
Logs

thread 'tokio-runtime-worker' panicked at 'The feature 'websocket' is not compiled in this binary. Please re-compile rathole', src/helper.rs:39:5
stack backtrace:
2023-11-16T03:25:59.518746Z  INFO config_watcher{path="/etc/rathole/config.toml"}: rathole::config_watcher: Start watching the config
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
Aborted
Environment:

OS: debian 12
rathole --version output: rathole v0.5.0
CPU architecture: aarch64

Read the release note carefully:

Because of the maintenance burden of linking TLS libraries, we don't compile the TLS feature in the release for embedded platforms anymore. If you need to use it, please build from the source by yourself. We will add it back when a pure rust tls library or a good cross-platform TLS libraries linking solution is available.

And as you can see:
https://github.com/rapiz1/rathole/blob/65b27f076cfb9789873223b803c6c394f91fd47d/Cargo.toml#L24-L25
TLS is required by websocket feature, so that's expected behavior.
TLDR, compile binary by yourself.

Thanks, I got it.


net: acquireThread might block for a long time

This was previously reported to the go security team.
When the cgo resolver is being used, we call the acquireThread function to limit the amount of concurrent cgo calls running and also to limit the amount of threads that will be ever created (by the net package) by the runtime for cgo calls. The limit is currently capped to 500.
https://github.com/golang/go/blob/9d836d41d0d9df3acabf7f9607d3b09188a9bfc6/src/net/cgo_unix.go#L148-L151
https://github.com/golang/go/blob/9d836d41d0d9df3acabf7f9607d3b09188a9bfc6/src/net/net.go#L674-L689
https://github.com/golang/go/blob/9d836d41d0d9df3acabf7f9607d3b09188a9bfc6/src/net/rlimit_unix.go#L11-L33
This might be problematic for services that connect to a user-provided hostnames.
The user-provided domain might be running on an "evil" nameserver that might trip timeouts (respond with SERVFAIL after ~5s). I have not tested this deeply, but I assume it would be possible to make the getaddrinfo block for 5-30s (assuming mostly default configuration in resolv.conf).
1-3 (Resolvers Count) * 2 (default attempts count) * 5s (default timeout).
Obviously with MITM it is simpler to trip timeouts.
We don't use the cgo resolver much these days on unix systems (except desktop linux, because of systemd nsswitch modules we don't support in the go resolver). On windows and darwin the cgo resolver is the default.

I think this should be at least made clear by the docs, currently we only note that:
https://github.com/golang/go/blob/9d836d41d0d9df3acabf7f9607d3b09188a9bfc6/src/net/net.go#L49-L50
This should probably mention that we have an internal cgo threads limit.

Also we probably should not force the use of cgo resolver for ".local" subdomains, so that use of the cgo resolver cannot be forced by an external user (consider a service that connects to a user-provided hostname). The go resolver should be able to resolve ".local" domains when there are no other nss modules in use than files and dns.
https://github.com/golang/go/blob/9d836d41d0d9df3acabf7f9607d3b09188a9bfc6/src/net/conf.go#L341-L347

Support context cancellation in acquireThread, so that when the thread limit is reached we don't call cgo stuff when the context is already cancelled (don't queue bunch of cgo calls when context is done).

I will send CLs for this.
CC @ianlancetaylor @golang/security @rolandshoemaker

@bcmills Can you provide more context on why you added the compiler/runtime label? In triage I'm not sure we're seeing how this should be addressed in the compiler and/or runtime. Thanks.

Huh — I don't remember. 😅
I think I misinterpreted acquireThread as a thing that acquires actual threads from the runtime and/or poller, but in practice it appears to only acquire semaphore tokens limiting implicitly-aquired thread. Sorry for the triage noise!

@mateusz834 was there anything left to do here? I think all of the proposed changes ended up landing.

@rolandshoemaker right, closing the issue


Multiple scrollactive on the page cause glitches

Hi there. Awesome plugin, but unfortunately I found out that it has issue, if I am trying to use multiple scrollactive on single page. For example, I have 2 navigations, main and mobile. I want scrollactive on both. If I try that, then I have glitches. For example if you set :duration="1000" then scrollbar will jerk. Or, even :duration="100" will not work at all (small values).
Is there's a way to fix it?

Another related issue - if I use active-class="active" then it adds active class only on last scrollactive

I'll take a look and see if I can replicate it, thanks for the feedback :)

Can you please update the lib and see if it's working now?

Glad to hear that, thanks :D


Using the bat files to create new solutions

Hi,
I was just wondering the correct parameters to pass into the python script to create a new project using the  core and model libraries
Thanks

@jonny2027 is it still or problem or you can close this issue?!

Sorry. I havent had a chance to test it but I will close it.
Thanks

There are two batch files.  CreateNewSolution.bat passes "app" to the python script and the name of the solution to create.  CreateNewLibrary.bat passes in "lib" and the name of the project to create.  Run them from MiniEngine's root folder, and the new folder will be created parallel to "Core".


View Components flush early

is it possible to flush view component result early?
https://www.stevesouders.com/blog/2009/05/18/flushing-the-document-early/
Currently my page is blocked trying to render 5-6 view components, i would like to flush them early then fill it up.
Is that possible in .net core mvc?

Flushing inside partials or view components doesn't write to the response stream. You can try doing a FlushAsync from the page that invokes the view component.
e.g.
@await Component.InvokeAsync("SomeComponent")
@await FlushAsync()

One caveat here is that that doing a FlushAsync from a Razor file would mean that the file cannot have a Layout page associated with it. Layouts require the entirety of the page content to be buffered, and flushing early prevents that.


Upgrade to scassandra 1.0.3.  Change CAS tests to use Scassandra.

Upgrades to Scassandra 1.0.3 (needed for scassandra/scassandra-server#143) and replaces existing CASRetryPolicyIntegrationTest with tests using Scassandra.

looking good in CI

:100:

Fixed formatting issue in SpeculativeExecutionTest (was in a number of places too in that file, so made it consistent).  This should be ready to go!

LGTM :+1:


After hitting escape, then enter (autoselect), typeahead:selected is fired, even if menu is closed

I'm using this to add tags (for a blog), and I've got the following code:
    $(document).ready(function() {
        $('#AddTag').typeahead({
            minLength: 0,
            highlight: true,
            autoselect: true,
        }, { /* Datasource */ });
        $('#AddTag').bind('typeahead:selected', OnAddTagFromTypeahead);
    });
    function OnAddTagFromTypeahead(evt, tag) {
        console.log(tag);
        // ...
    }

When I hit escape to close the dropdown, then hit enter, it is firing the typeahead:selected event, but I don't think it should be.

Should be fixed in v0.11.


[$500] Chat - Two pop-ups are displayed at the same time

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Go to URL https://staging.new.expensify.com/
Login with any account
Open any chat with several comments or send them
Hover the mouse over any comment -> add a reaction
Hover over another comment

Expected Result:
The previous pop-up should close when the next pop-up opens
Actual Result:
Two pop-ups are displayed at the same time
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/93399543/844008e9-1d70-4faf-96d7-9d9e95d7b29d
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01df547c67743aa751
Upwork Job ID:<PHONE_NUMBER>945669632
Last Price Increase: 2023-11-22

Proposal
Please re-state the problem that we are trying to solve in this issue.
Two mini context menu appears at the same time when EmojiPicker is opened
What is the root cause of that problem?
We prevent closing mini context menu below when opening EmojiPicker
https://github.com/Expensify/App/blob/a273354130bbbc057dee4eefb1f9ac0371bec26a/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L130
https://github.com/Expensify/App/blob/a273354130bbbc057dee4eefb1f9ac0371bec26a/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L143
https://github.com/Expensify/App/blob/a273354130bbbc057dee4eefb1f9ac0371bec26a/src/pages/home/report/ContextMenu/ContextMenuActions.js#L73
This is the root cause
What changes do you think we should make in order to solve the problem?
shouldKeepOpen was used to prevent closing the mini context menu when EmojiPicker is opened. Looks like an intentional behavior
Simply updating
https://github.com/Expensify/App/blob/a273354130bbbc057dee4eefb1f9ac0371bec26a/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L143
to
         openContextMenu: () => setShouldKeepOpen(false),

would solve the issue
Note: We might need to remove all use of shouldKeepOpen and openContextMenu

Result

What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
Two mini context menu appears at the same time when EmojiPicker is opened
What is the root cause of that problem?
We prevent closing mini context menu using shouldKeepOpen when opening EmojiPicker
What changes do you think we should make in order to solve the problem?
We need to remove shouldKeepOpen here.
https://github.com/Expensify/App/blob/0cca90ab9aa7fd9467ef45ca35c4d0ad3c3334ae/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L130
What alternative solutions did you explore? (Optional)

I'm heading out for the Thanksgiving holiday and will be back bright and early Monday morning.
If something pops up that needs urgent attention please reapply label or ask in slack.

@aimane-chnaif  you are right.
This is not bug

@abekkala Seems like an intentional behavior. Kindly check if this is still a bug, after back from holidays.

I agree, this is expected and not a bug. Closing