Reply Pilot Search

Tato stranka popisuje modul reply-pilot-search/.

Role modulu

  • provozuje Spring Boot search aplikaci a oficialni Solr jako dva kontejnery jednoho atomicky nasazovaneho Compose modulu
  • 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/
  • oba kontejnery bezi jako non-root uzivatel pres HOST_UID a HOST_GID
  • Spring Boot 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 jsou v reply-pilot-search/data/solr/; heartbeat a sync state jsou v reply-pilot-search/data/
  • GET /healthz vraci stav HTTP vrstvy, Solr spojeni 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 vcetne vsech registraci z party_vat_registration a jejich katalogovych nazvu
  • 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, email_thread_reply a reply_pilot_task

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 `.

Company dokument obsahuje raw i normalizovanou hodnotu kazde VAT registrace, jurisdiction code, country code a lokalni nazev. Subtitle zobrazuje vsechny registrace; search necita kompatibilitni organization scalar.

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 60 sekund
  • modul pri kazdem syncu nacte aktualni indexovany dataset z reply-pilot-db a do Solru posila jen rozdily oproti poslednimu syncu; nejde o CDC ani DB change feed
  • task-company resolution pouziva jeden materialized CTE pro vsechny tasky, aby databaze neopakovala stejny scan pro kazdy task
  • heartbeat se uklada do data/search-heartbeat.json
  • otisk posledniho indexovaneho stavu se uklada do data/search-sync-state.json
  • prvni Java sync po prechodu z Python implementace jednou prepocita fingerprinty a znovu odesle existujici dokumenty; dalsi behy opet posilaji jen diff