Reply Pilot Search

Tato stranka popisuje modul reply-pilot-search/.

Role modulu

  • provozuje Solr index uvnitr samostatneho moduloveho kontejneru
  • vystavuje interni HTTP API GET /api/search
  • pravidelne synchronizuje index z reply-pilot-db
  • vraci vysledky s url_path, ktere backend predava web aplikaci

Runtime

  • modul bezi jako interni HTTP sluzba na siti reply-pilot-internal
  • backend ho vola pres http://reply-pilot-search:5000
  • operatorum publikuje host port HOST_HTTP_PORT, defaultne http://127.0.0.1:9093
  • Solr admin UI a Solr HTTP API publikuje na HOST_SOLR_PORT, defaultne http://127.0.0.1:9094/solr/
  • kontejner bezi jako non-root uzivatel pres HOST_UID a HOST_GID
  • Python i Solr loguji vyhradne na stdout; lokalne pouzij docker compose logs
  • Upstream Solr launcher vyzaduje interni SOLR_LOGS_DIR; image ho napevno smeruje do /dev/shm, request-file logger je vypnuty a tato hodnota neni uzivatelska konfigurace ani persistentni log destination.
  • Solr data, heartbeat a sync state jsou v reply-pilot-search/data/
  • GET /healthz vraci stav HTTP vrstvy, Solr procesu i posledniho syncu
  • oba host porty jsou defaultne bindnute jen na 127.0.0.1; verejne vystaveni ma jit az pres vedome nastaveny bind nebo pres kontrolovanou reverse proxy vrstvu

Indexovany obsah

  • company: organizace z party modelu
  • person: osoby z party modelu
  • email: zaznamy z activity_email
  • activity: note, call a meeting zaznamy z activity modelu
  • task: lokalni Reply Pilot tasky z task_jira pro work typy supplier_onboarding a email_thread_reply

Search preferuje emailove zaznamy a umi filtrovat podle typu objektu. Bez uvozovek se kazde slovo hleda jako pravostranny prefix, napr. bak odpovida Bakly. Presny vyraz bez automatickeho prefixu se pise do uvozovek; podporovane jsou ", ' a `.

Task dokumenty reprezentuji interni tasky v aplikaci. Search indexuje task_id, Jira key, cache Jira summary, cache plain-text Jira description, work type, status, navazanou party, assignee display a navazany email-thread kontext. Primarni URL vysledku je vzdy /tasks/<task_id>; Jira key je jen volitelne sekundarni pole pro externi akci v UI.

Company a task search dokumenty obsahuji visibility metadata, aby backend mohl search requesty scopeovat podle aktualniho app_user.id. company.view_all neposila owner filtr a uzivatel muze hledat vsechny firmy i tasky. company.view_assigned vraci company dokumenty, kde default_email_sales_user_id odpovida aktualnimu uzivateli, a task dokumenty se stejnym pravidlem jako task list: task bez navazane party je viditelny, task navazany na ne-company party je viditelny, task navazany na firmu je viditelny jen kdyz party_organization.default_email_sales_user_id = app_user.id. Bez company.view_all i company.view_assigned search nevraci company ani task dokumenty. Email/person/activity vysledky jsou mimo company.view_all zamerne potlacene, aby se pres navazane objekty neprozrazovaly skryte firmy.

Synchronizace

  • sync bezi v intervalu SEARCH_SYNC_INTERVAL_SECONDS, defaultne kazdych 5 sekund
  • modul cte z reply-pilot-db a do Solru posila jen rozdily oproti poslednimu syncu
  • heartbeat se uklada do data/search-heartbeat.json
  • otisk posledniho indexovaneho stavu se uklada do data/search-sync-state.json