monitor.series-window
The samples of a time series from one moment up to (not including) another, checking they are in time order.
1.0.0 · published 2026-10-03 by charlie · Anterra
Pinned by 12 tests, run in TypeScript, Python and Rust.
What it does
Picks the samples of a stored metric series that fall in a window, and owns the `MetricSample` type the other `monitor.*` metric capabilities share: `{ at, value }`, `at` in Unix seconds and `value` a whole number in whatever unit the metric uses (milliseconds, bytes, a request counter). Scale decimals to integers first (a CPU percentage in basis points), so every language agrees on every answer.
## Why half-open
For example
series_window(samples ×4, 150, 250)→ ×2 keeps the samples inside the windowseries_window(samples ×2, 100, 200)→ ×2 a sample exactly at from is includedseries_window(samples ×2, 100, 200)→ ×1 a sample exactly at to is excluded, so back-to-back windows never share one
The function
The same function in TypeScript, Python and Rust, pinned by the same tests. Pick your language; the choice follows you around the registry.
pub fn series_window(samples: &[MetricSample], from: i64, to: i64) -> Vec<MetricSample>
| samples | MetricSample[] | in strictly ascending time order, as a monitor stores them |
| from | int | the first second included, Unix seconds |
| to | int | the first second excluded; equal to from is an empty window |
| returns | MetricSample[] |
The type it declares, generated into your project
/// One metric reading at a moment, in whole units (ms, bytes, requests); scale decimals first.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct MetricSample {
/// Unix seconds
pub at: i64,
pub value: i64,
}
Your code names it in one line, in the file that uses it
fune!(monitor.series-window@^1); // then call series_window(…)
Imports name this capability’s declared dependencies, which fune builds next to it in your project; each one links to its page.
use super::funejson::Value; ← the fune runtime: the JSON value the test vectors use; fune build keeps it only where a signature takes one
/// The samples with from <= at < to. Half-open, so consecutive windows
/// (the last hour, the hour before) never count a sample twice.
///
/// # Panics
/// Panics when from is after to, or the samples are not strictly ascending.
pub fn series_window(samples: &[MetricSample], from: i64, to: i64) -> Vec<MetricSample> {
if from > to {
panic!("from must not be after to: {} > {}", from, to);
}
let mut out = Vec::new();
for (i, s) in samples.iter().enumerate() {
// Checked over the whole series, not just the window: a misordered
// store gives wrong answers everywhere, so it should fail everywhere.
if i > 0 && s.at <= samples[i - 1].at {
panic!("samples must be in strictly ascending time order: {} follows {}", s.at, samples[i - 1].at);
}
if s.at >= from && s.at < to {
out.push(MetricSample { at: s.at, value: s.value });
}
}
out
}
/// A `MetricSample` from its JSON form, for adapters of capabilities built on this one.
pub fn sample_from_value(v: &Value) -> MetricSample {
MetricSample { at: v.get("at").as_i64(), value: v.get("value").as_i64() }
}
pub fn samples_from_value(v: &Value) -> Vec<MetricSample> {
v.as_arr().iter().map(sample_from_value).collect()
}
pub fn sample_to_value(s: &MetricSample) -> Value {
Value::obj(vec![("at", Value::Int(s.at)), ("value", Value::Int(s.value))])
}
fn whole(v: &Value) -> i64 {
match v {
Value::Int(i) => *i,
_ => panic!("from and to must be whole seconds"),
}
}
pub fn fune_vector(args: &[Value]) -> Value {
let samples = samples_from_value(&args[0]);
let out = series_window(&samples, whole(&args[1]), whole(&args[2]));
Value::Arr(out.iter().map(sample_to_value).collect())
}Install
fune build
With that line in your source, in a Rust project (language rust in fune.project), fune build resolves it and nothing else, pins them in fune.lock, downloads only the Rust package of each, and builds the code above into your project’s .fune/build, one readable file per capability with a header linking back here. A crate’s build.rs runs it before every compile. Or pin a range in fune.project and build in one step:
fune add monitor.series-window
The manifest, vectors and README with only the Rust implementation. Install it without the registry with fune add ./monitor.series-window-1.0.0-rust.fune, or fetch it from a terminal with fune pull monitor.series-window@1.0.0:rust.
The whole function, every language, is one file too: monitor.series-window-1.0.0.fune, 9,491 bytes, sha256 b34498a4d87e3c9ae6c5bb56c9a194952205a5cd37f465b3e3485541c6053dca. It installs into a project of any language.
Customise it in your app
The seams this capability offers. Put a marker directly above a function of your own and fune build wires it into the built code; the package on the registry is not changed, the built file’s header lists it under CUSTOMISED, and fune hooks lists every hook in the project. How hooks work.
before — your function gets the arguments and returns them, changed or not, or throws to refuse the call.
// fune: before monitor.series-window
after — your function gets the result and the arguments, and returns the final result.
// fune: after monitor.series-window
replace — it requires no other capability, so there is no dependency to replace.
step — your function runs at a numbered point inside the function’s body, receives the in-scope values it names as parameters, and may return replacements. List the points with fune show monitor.series-window --steps.
// fune: step monitor.series-window after <n|label>
Tests
A version published now needs at least 8 tests for every function, and one that expects the error for each function that throws; the registry refuses it otherwise. fune verify --all runs each case in TypeScript, Python and Rust, and a project runs them again with fune verify. This page lists the cases; it does not run them. The exact JSON is vectors.json.
| Case | Arguments | Expected | |
|---|---|---|---|
| keeps the samples inside the window | samples ×4, 150, 250 | → | ×2 |
| a sample exactly at from is included | samples ×2, 100, 200 | → | ×2 |
| a sample exactly at to is excluded, so back-to-back windows never share one | samples ×2, 100, 200 | → | ×1 |
| an empty window when from equals to | samples ×1, 100, 100 | → | |
| an empty series is an empty window | , 0, 1,000 | → | |
| a window before every sample is empty | samples ×1, 0, 500 | → | |
| negative values and times before 1970 are kept as they are | samples ×3, -60, 1 | → | ×2 |
| a window covering everything returns every sample | samples ×3, 0, 4 | → | ×3 |
| from after to is an error | , 200, 100 | → | error: from must not be after to: 200 > 100 |
| two samples at the same second are an error | samples ×2, 0, 1,000 | → | error: samples must be in strictly ascending time order: 100 follows 100 |
Show the other 2 tests
| Case | Arguments | Expected | |
|---|---|---|---|
| misordered samples outside the window are still an error | samples ×2, 0, 50 | → | error: samples must be in strictly ascending time order: 100 follows 300 |
| a fractional bound is an error | , 0.5, 10 | → | error: from and to must be whole seconds |
More from the author
The window is `from <= at < to`. Back-to-back windows (this hour, the hour before) then never count the same sample twice, which a closed window would.
## Order is checked
Samples must be strictly ascending in time. The whole series is checked, not only the part inside the window: a store that returns rows out of order gives wrong rates, alerts and uptimes everywhere, so it is refused everywhere. Two samples at the same second are refused too: which one is "the" value then is a guess.
## Errors
- `from must not be after to` - `samples must be in strictly ascending time order` - `from and to must be whole seconds`
Files
| Path | Bytes |
|---|---|
| README.md | 1,069 |
| impl/python.py | 1,076 |
| impl/rust.rs | 1,814 |
| impl/typescript.ts | 1,083 |
| vectors.json | 2,082 |