oxidecomputer / oxidecomputer/omicron

nexus-inventory: injectable time source for CollectionBuilder

Open
#11,216 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

RFD 726's simulator runs on a simulated clock, and enforces a timestamp-leak invariant: every timestamp in produced output must fall within [epoch, now] on that clock. Collections currently make that impossible: CollectionBuilder stamps time_started at construction and time_done at build via now_db_precision(), with no injection point. Input::reference_time — the "now" that diagnosis engines compare against — is exactly that time_done, so until the sim can supply it, the planner's clock moves on its own.

Note the fix should cover more than those two fields: several other now_db_precision() call sites stamp time_collected on individual items (e.g. L231, L357, L634), so a caller-supplied clock (or time source) on the builder needs to feed those too, or wall-clock readings still leak into collections.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in nexus/inventory/src/builder.rs at the linked CollectionBuilder construction, build, and time_collected call sites, then read nexus/fm/src/analysis_input.rs around Input::reference_time. Trace how the builder currently calls now_db_precision() and make the caller-supplied time source cover every listed timestamp. Done means collections use the supplied clock consistently, including time_done and reference_time.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.