Skip to content

Enforce maximum value for GlobalConfig.refresh_rate#439

Merged
timmarkhuff merged 6 commits into
mainfrom
refresh-rate-resilience
Jun 17, 2026
Merged

Enforce maximum value for GlobalConfig.refresh_rate#439
timmarkhuff merged 6 commits into
mainfrom
refresh-rate-resilience

Conversation

@timmarkhuff

@timmarkhuff timmarkhuff commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Changes

  • Add le=86400 to GlobalConfig.refresh_rate, capping the maximum value at 1 day.
    Values above this are now rejected at construction time with a clear ValidationError.

Notes

This PR is paired with groundlight/edge-endpoint#427, which makes the model-updater
loop more responsive to set_config calls. Neither PR depends on the other for correctness.

@timmarkhuff timmarkhuff changed the title Refresh rate resilience Make GlobalConfig.refresh_rate Optional with 1-day cap Jun 10, 2026
@timmarkhuff timmarkhuff force-pushed the refresh-rate-resilience branch from aa768c7 to acd8f9f Compare June 10, 2026 22:59
Tim Huff and others added 2 commits June 10, 2026 16:12
- Change refresh_rate from float to Optional[float] with gt=0 and le=86400.
  Values above 86400s (1 day) are rejected at construction time; use None to
  disable refresh polling entirely.
- Previously, values like 9999999999999 were accepted and silently caused
  time.sleep() to raise OverflowError in the inference-model-updater container,
  crashing it into CrashLoopBackOff.

Co-authored-by: Cursor <cursoragent@cursor.com>
@timmarkhuff timmarkhuff changed the title Make GlobalConfig.refresh_rate Optional with 1-day cap Enforce maximum value for GlobalConfig.refresh_rate and make it optional Jun 10, 2026
@timmarkhuff timmarkhuff force-pushed the refresh-rate-resilience branch from bb85e26 to fb33eb3 Compare June 10, 2026 23:22
@timmarkhuff timmarkhuff requested a review from honeytung June 11, 2026 23:51
@timmarkhuff timmarkhuff changed the title Enforce maximum value for GlobalConfig.refresh_rate and make it optional Enforce maximum value for GlobalConfig.refresh_rate Jun 16, 2026

@honeytung honeytung left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@timmarkhuff timmarkhuff merged commit b5dce2d into main Jun 17, 2026
8 checks passed
timmarkhuff added a commit to groundlight/edge-endpoint that referenced this pull request Jun 18, 2026
## Background

When the `inference-model-updater` sleeps between update cycles, it does
not respond to
`ExperimentalApi.edge.set_config` calls. If `refresh_rate` is high, this
means adding or
removing detectors can be delayed by the full sleep duration.

## Changes

1. **Move `get_active_detector_ids()` onto `DatabaseManager`** as a
class method. The
module-level function in `edge_config_manager.py` delegates to it; no
callers break.

2. **Replace `time.sleep` with `_wait_for_next_cycle`** in the
model-update loop. Polls
every 2s and wakes early if `set_config` added/removed a detector or
`refresh_rate`
changed. The detector baseline is captured once per cycle (before the
per-detector loop)
and shared with both the mid-cycle check and the wait, so a config
change detected
mid-cycle also causes `_wait_for_next_cycle` to return immediately
rather than sleeping.

3. **Early-exit mid-cycle** — the per-detector for-loop checks after
each detector and
breaks early if the config changed, restarting the outer loop
immediately.

## Notes

Paired with groundlight/python-sdk#439, which enforces a 1-day cap on
`refresh_rate`.

---------

Co-authored-by: Tim Huff <thuff@axon.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Auto-format Bot <autoformatbot@groundlight.ai>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants