trustgraph-ai/trustgraph

Summary The Kafka pub/sub backend (trustgraph-base/trustgraph/base/kafka_backend.py) is functionally complete but has blocking issues in practice. When deployed, consumers appear to hang/block and messages are not processed. The root cause has not been identified. Current State The implementation covers: Topic parsing and naming (class:topicspace:topic → topicspace.class.topic) Retention policy: 7 days for flow, 5 minutes for request/response/notify Producer with delivery confirmation and Kafka header support Consumer with competing-consumer (shared group) vs per-subscriber (unique group) semantics Acknowledge (commit offset) and negative acknowledge (seek back) Topic lifecycle via AdminClient: create_topic, delete_topic, topic_exists, ensure_topic Factory integration in pubsub.py with CLI args and env vars SASL/SSL auth config passthrough Unit tests for parsing, retention, factory, and CLI args (all passing) Known Issues 1. Consumer blocking (undiagnosed) When running with --pubsu

Summary Document-RAG currently performs a single retrieval pass: extract concepts → embed → fetch matching chunks → synthesise answer. This works well when the answer lives in one or two chunks, but falls short for questions that span multiple documents or require connecting information across sections. A multi-hop retrieval loop would let the LLM read initial chunks, identify what information is still missing, and issue follow-up queries — iterating until it has enough context to answer. Motivation Example questions that need multi-hop: "How does the data retention policy interact with the GDPR compliance requirements?" — retention policy is in one document, GDPR requirements in another "Compare the authentication mechanisms described in the v2 and v3 architecture documents" — needs chunks from two different documents "What are all the prerequisites for deploying the production pipeline?" — prerequisites may be scattered across setup guide, infrastructure doc, and runb

Description Several timeout values are hardcoded throughout the codebase rather than being configurable via CLI arguments or environment variables. Examples: Bootstrapper IAM/config/flow timeouts: `timeout=10` and `timeout=30` in `trustgraph-flow/trustgraph/bootstrap/initialisers/` (workspace_init.py, default_flow_start.py) Librarian fetch timeout: `timeout=120` in `trustgraph-flow/trustgraph/retrieval/document_rag/rag.py:98` Config client default: `CONFIG_TIMEOUT = 10` in `trustgraph-base/trustgraph/base/config_client.py:5` Gateway default: `default_timeout = 600` in `trustgraph-flow/trustgraph/gateway/service.py:36` Problem In production environments with variable network latency (e.g. cross-region Cassandra, overloaded message bus), hardcoded timeouts can cause spurious failures. Operators currently have no way to tune them without modifying source code. Suggested approach Please PR against the latest release/vX.Y branch. Pick one area to start with (e.g. the bootstrapper timeou

kg-extract-agent allows using the agent framework for knowledge extraction - this hasn't been tested in a while, find out if it it works

Files like prompt_manager.py, socket_client.py, and bulk_client.py have 54+ bare except: clauses that silently swallow KeyboardInterrupt/SystemExit. Each one is a self-contained fix. Please PR against the latest release/vX.Y branch.