Add end_epoch for query time range customization

[landaudiogo]

Introduce a new end_epoch option that specifies the end of the Prometheus query window. When used together with the existing history duration option, users can define an arbitrary time range instead of being limited to querying metrics relative to the current time.

Closes #474

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b9103d91-2df3-4bca-b7f0-b7e68fcf55e0

📥 Commits

Reviewing files that changed from the base of the PR and between 58ead56 and e2c3a3e.

📒 Files selected for processing (1)

• robusta_krr/core/abstract/strategies.py

🚧 Files skipped from review as they are similar to previous changes (1)

• robusta_krr/core/abstract/strategies.py

---

Walkthrough

The metrics pipeline now accepts an explicit end timestamp. Strategy settings provide it, the runner forwards it through Prometheus services, and metric queries derive their start time while preserving the end time across batched requests.

Changes

Explicit metrics end time

Layer / File(s)	Summary
End time settings and recommendation wiring robusta_krr/core/abstract/strategies.py, robusta_krr/core/runner.py	StrategySettings adds end_epoch and an end_datetime UTC conversion property; recommendation calculation passes this value to Prometheus gathering.
Metrics end time propagation robusta_krr/core/abstract/metrics.py, robusta_krr/core/integrations/prometheus/metrics_service/..., robusta_krr/core/integrations/prometheus/loader.py	Metric and service interfaces accept end_time, and Prometheus gathering forwards it through the loader chain.
Prometheus query time window robusta_krr/core/integrations/prometheus/metrics/base.py	Metric loading derives start_time from the supplied end time and reuses the same end time for recursive batches.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant StrategySettings
  participant Runner
  participant PrometheusMetricsLoader
  participant PrometheusMetricsService
  participant PrometheusMetric
  participant Prometheus
  StrategySettings->>Runner: provide end_datetime
  Runner->>PrometheusMetricsLoader: gather_data(end_time)
  PrometheusMetricsLoader->>PrometheusMetricsService: gather_data(end_time)
  PrometheusMetricsService->>PrometheusMetric: load_data(end_time)
  PrometheusMetric->>Prometheus: query from end_time - period to end_time

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 45.45% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: adding an end_epoch option for query time range customization.
Description check	✅ Passed	The description is directly related to the change and explains the new time-range behavior.
Linked Issues check	✅ Passed	The PR supports the linked goal of running krr over a specific timeframe by adding an end time and wiring it through.
Out of Scope Changes check	✅ Passed	The changes are focused on threading the new end time through existing metrics and runner code with no obvious unrelated work.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

robusta_krr/core/runner.py (1)

333-333: 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Propagate end_time to load_pods for historical pod discovery.

load_pods queries Prometheus for pods that existed within history_timedelta. Because end_datetime is not passed to it, the search window is evaluated relative to the current time (now()).

If a user configures end_epoch to query a historical event (e.g., a week ago), KRR will search for pods that existed in the current window rather than the historical window. This will result in missing pods or falling back to the current Kubernetes API state, breaking historical evaluation.

Please update the load_pods method signature across the loader chain to accept end_time and pass it down to the underlying Prometheus query.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@robusta_krr/core/runner.py` at line 333, Update the runner call that invokes
prometheus_loader.load_pods to pass the configured historical end time, and
propagate this end_time parameter through each load_pods implementation and
delegation in the loader chain to the underlying Prometheus query. Ensure the
query uses the supplied end_time as the window endpoint instead of defaulting to
now(), while preserving current behavior for callers without a historical end
time.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@robusta_krr/core/abstract/strategies.py`:
- Line 52: Update the end_epoch field definition to use Pydantic’s
default_factory with time.time instead of evaluating time.time() during class
definition, so each new instance receives its creation-time timestamp while
retaining the existing nonnegative constraint.

---

Outside diff comments:
In `@robusta_krr/core/runner.py`:
- Line 333: Update the runner call that invokes prometheus_loader.load_pods to
pass the configured historical end time, and propagate this end_time parameter
through each load_pods implementation and delegation in the loader chain to the
underlying Prometheus query. Ensure the query uses the supplied end_time as the
window endpoint instead of defaulting to now(), while preserving current
behavior for callers without a historical end time.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 30d6a25f-a138-4806-8970-ae58ddfb0735

📥 Commits

Reviewing files that changed from the base of the PR and between 437d81f and a91bea3.

📒 Files selected for processing (7)

• robusta_krr/core/abstract/metrics.py
• robusta_krr/core/abstract/strategies.py
• robusta_krr/core/integrations/prometheus/loader.py
• robusta_krr/core/integrations/prometheus/metrics/base.py
• robusta_krr/core/integrations/prometheus/metrics_service/base_metric_service.py
• robusta_krr/core/integrations/prometheus/metrics_service/prometheus_metrics_service.py
• robusta_krr/core/runner.py