#31 and #36 bump tonic-build alone to 0.14 and break the build outright:
0.14 moved prost codegen out to tonic-prost-build, so
`tonic_build::configure()` no longer exists. Both repositories also pin
`tonic = "0.12"` as the runtime beside it, and codegen from 0.14 against
a 0.12 runtime would be incoherent even if it compiled.
So the whole set moves together, in agent and in search:
tonic 0.12 -> 0.14
tonic-build 0.12 -> tonic-prost-build 0.14 (build-dependency)
prost 0.13 -> 0.14
tonic-prost new runtime dependency
Two consequences worth naming. The generated code now reaches for
`tonic_prost::ProstCodec`, so tonic-prost has to be a real dependency
rather than something the build script pulls in. And prost had to move
with it: tonic-prost 0.14 wants prost 0.14, so leaving ours at 0.13
left the generated types deriving a `Message` trait from a different
prost than the one the codec demanded.
tonic's `tls` feature is gone, replaced by one feature per crypto
provider. `tls-ring` is the like-for-like choice: it is the rustls-plus-
ring pairing `tls` used to mean, and the agent hands its own CA and
identity to ClientTlsConfig for mTLS, so it needs no root store.
The call sites did not change at all -- transport::{Certificate,
Channel, ClientTlsConfig, Identity} and include_proto! are all still
where they were.
Verified by building both, since no CI job compiles Rust: agent and
search check clean, 34 agent tests and 24 search tests pass.
Extends the agent, ingest, storage, api, and web with Windows Event
Log/ETW sourcing and Tantivy-backed free-text search, per the approved
Phase 1 plan.
- CLAUDE.md: materialized on disk (never existed as a file before) with
a new Phase 1 "done looks like" section.
- agent: Windows Event Log (EvtSubscribe) and ETW sources, Windows
service wrapper (install/uninstall/run-service), both feature- and
target_os-gated so Linux builds/tests/clippy stay unaffected. Also
fixed two pre-existing Phase 0 clippy gaps (dead-code on
default-features-only builds, a type-inference edge case) found while
testing every feature combination properly for the first time.
UNVERIFIED on real Windows -- no Windows toolchain existed anywhere in
the build environment; flagged prominently in three places.
- proto/ingest: new record_id field, assigned once server-side in
ingest's gRPC front end so ClickHouse and Tantivy agree on the same ID
for the same record.
- storage: record_id column + bloom filter index, verified against a
live ClickHouse.
- search: new service, Tantivy index, rskafka consumer as an independent
second consumer group on the same Redpanda topic ingest already reads.
- api/web: new /search endpoint and page, sharing the query page's
result-table shape and component.
- hack/windows-fixture: sends realistic Windows-shaped data straight to
ingest, so the pipeline's handling of it is verifiable without a
Windows host.
Verified end-to-end on the live docker-compose stack: the same record_id
comes back from both /query and /search for the same log line, including
for windows-fixture's synthetic Windows Event Log data. Real bugs found
and fixed along the way: api/Dockerfile missing proto/ in its build
context, search's logs being completely silent (RUST_LOG gap), and
search/target/ missing from .gitignore/.dockerignore.
jcoffey-dev