Find answers from the community

Updated last year

For some reason on a second message,

At a glance

The community members are experiencing an issue with their code where it breaks on the second message if the content_s3_keys is empty. They encountered errors related to the TCPTransport being closed and an asyncio.locks.Event object being bound to a different event loop. The community members believe the issue was related to the shared service_context across the application, and their resolution was to not share the service_context. They also mentioned they will likely migrate to a new version to permanently eliminate the service_context issue.

For some reason on a second message, this code breaks
Plain Text
         if not content_s3_keys:
             raise ValueError("s3_keys_to_summarize is empty")
 
         temp_file_dir = "/tmp/llama-indexer/s3-files"
 
         # TODO extension
         # TODO async
         file_paths = [
             download_file_from_s3(
                 bucket_name="usable-dev",
                 key=key,
                 target_dir=temp_file_dir,
                 extension="",
             )
             for key in content_s3_keys
         ]
 
         reader = SimpleDirectoryReader(input_files=file_paths)
         documents = reader.load_data()
 
         service_context = get_service_context(model=model)
 
         summary_index = SummaryIndex.from_documents(
             documents, service_context=service_context
         )
 
         agent_or_engine = CondensePlusContextChatEngine.from_defaults(
             retriever=summary_index.as_retriever(),
             service_context=get_service_context(model=model),
             chat_history=history,
             memory=ChatMemoryBuffer.from_defaults(  # pyright: ignore
                 chat_history=history, token_limit=128000
             ),
         )

We get the error
unable to perform operation on <TCPTransport closed=True reading=False 0x2c69a4600>; the handler is closed

If we stop the server in between the first and second request we get
<asyncio.locks.Event object at 0x2b9d146d0 [unset]> is bound to a different event loop

And after restarting the server it works
L
m
4 comments
which part in this code block breaks?
We figured out we think it was the service context that we shared across the application
Our resolution was to just not share the service context and it started working
But we will probably just migrate to the new version tomorrow and permanently eliminate service context visa vi
Add a reply
Sign up and join the conversation on Discord