# `Lightning.LogLines.SearchVectorWorker`
[🔗](https://github.com/OpenFn/lightning/blob/main/lib/lightning/log_lines/search_vector_worker.ex#L1)

Backfills the full-text `search_vector` on `log_lines` rows.

Log lines are inserted with `search_vector` left `NULL`; the vector is built
here rather than on the insert path, keeping `to_tsvector` off the hot path of
high-volume log ingestion. Search is eventually consistent as a result,
typically catching up within a minute.

Two database objects support this: `safe_to_tsvector(regconfig, text)`, which
builds the vector while tolerating NULL and oversized input, and a partial
index over `search_vector IS NULL`, which keeps locating pending rows cheap as
the table grows. Vectors use the `english_nostop` config to match the read
side (`Lightning.Invocation`), which queries with
`to_tsquery('english_nostop', ...)`.

Each run drains pending rows newest-first, in batches up to a per-run budget
(batch size and max batches are configurable via `Lightning.Config`). A run
that exhausts its budget leaves backlog behind
and enqueues an immediate follow-up ("snowball"); otherwise the minute-ly cron
tick keeps pace. The worker runs on the dedicated `search_indexing` queue at
concurrency 1, so only one job executes at a time, and the cron tick and the
snowball carry distinct `trigger` args, so job uniqueness allows one of each to
queue but never a duplicate.

---

*Consult [api-reference.md](api-reference.md) for complete listing*