cache-miss-then-hit-a
Purpose
With cache → forward enabled, two identical A queries both return a
successful answer, the stub peer receives exactly one upstream query from
Conduit (cold miss fill; warm path skips the peer), the warm answer’s TTL is
strictly lower than the cold fill, and Conduit metrics record one cache
miss then one hit (with matching answer_source response labels).
Results appear on the Conduit behavior matrix (one stub peer).
How it works
- The stub peer answers
www.smoke.test→192.0.2.20with a positive TTL. - Conduit uses the cache-forward profile (Prometheus scrape enabled).
- The harness snapshots peer logs and
/metrics, issues the A query via Conduit (cold miss), waits two seconds, issues the same query again (warm hit), then checks log and metrics deltas. - Each DNS step must be NOERROR with at least one answer RR; the peer must show one Conduit-sourced query; answer TTL must decrease; and metrics must show miss+forward then hit+cache increments of one each.
Outcomes
| Outcome | Meaning for operators |
|---|---|
| pass | Answers succeeded, peer saw one Conduit query, TTL decayed, and cache metrics recorded miss then hit. |
| fail | DNS, peer-query, TTL, or metrics assertion failed — investigate the cache/forward path. |
| skip | This profile or peer is out of scope (cache-forward on the Conduit-behavior stub only). |
| characterized | Not used for this case today. If it appeared, it would mean a documented peer-specific quirk rather than a Conduit regression. |
Matrix: conduit (Conduit behavior)
Suites: full
Oracles: property, peer-query-count, sequence, metrics-delta