Hi Xinqi, all, Thanks for the write-up. The table-model variable path and the object-form compatibility in #128 both look right to me, and the $__evaluationTime split in #129 is a good call -- keeping Instant out of ordinary range predicates avoids a whole class of surprises.
One thing about $__activeFrom I would raise while the macro is still new. The liveness window is a compile-time constant, and the comment above it is explicit that ageing out is the intended behaviour: // nodeActiveTTL is the template-variable liveness window. A node is // considered active only if its most recent sample falls within the last // nodeActiveTTL. The bridge writes samples with their Prometheus scrape // timestamp, so this is "the node produced a scrape within the last // nodeActiveTTL"; a node that stops producing samples ages out of the // window and disappears from the variable. const nodeActiveTTL = 5 * time.Minute So this is not about the mechanism, which reads right to me. It is about the threshold being fixed at five minutes. That value follows from the Prometheus scrape cadence the comment names, and for that source it is a good default. But $__activeFrom is a general macro available to any table-model variable query, and a device that reports every ten or fifteen minutes is ordinary in the industrial deployments IoTDB targets. Those nodes have not stopped producing samples; they simply produce them more slowly than the window allows. I ran this against IoTDB 2.0.8 in Docker, through the plugin's own /getVariables handler with the real RPC executor (tableExecutor left nil). Two rows, differing only in how old their last sample is: === RUN TestZZActiveFromExcludesSlowReporters nodeActiveTTL (hardcoded) = 5m0s fast: last sample 1m0s ago slow: last sample 10m0s ago CONTROL (no macro) -> [fast slow] WITH $__activeFrom -> [fast] expanded lower bound = 2026-08-28T11:34:00.972+00:00 --- PASS: TestZZActiveFromExcludesSlowReporters (0.12s) === RUN TestZZActiveFromTTLIsNotConfigurable expansion is a function of wall clock and the constant only: 2026-08-28T11:34:00.972+00:00 no datasource field changes it; nodeActiveTTL = 5m0s is a compile-time constant --- PASS: TestZZActiveFromTTLIsNotConfigurable (0.00s) The control line is there so the one after it means something: without the macro both rows come back, so the data and the whole handler path are fine. The second test is the one that says the window is not reachable from configuration -- changing the datasource fields leaves the expansion identical, because it is a function of the wall clock and that constant alone. Two ways to widen it, either seems fine: - a datasource setting for the liveness window, defaulting to 5m so existing dashboards do not change; or - an optional argument on the macro, $__activeFrom(15m), defaulting to 5m when omitted -- closer to how $__interval and friends already read. The reason I raise it now rather than later is that the macro is a public surface. Once dashboards depend on its current shape, adding an argument or a setting stops being free. Happy to send the test as a PR if that is useful; it is self-contained and needs only a local IoTDB. Best regards, Zihan Dai
