Feat/align plugins with utils v0.4.0 - #173
Open
Aliaksei-Kharlap wants to merge 15 commits into
Open
Aliaksei-Kharlap wants to merge 15 commits into
Aliaksei-Kharlap wants to merge 15 commits into
Conversation
Aliaksei-Kharlap
force-pushed
the
feat/align-plugins-with-utils-v0.4.0
branch
from
September 20, 2026 12:33
cf8a1cf to
1bcdf32
Compare
…config Both entry points read the same sources in the same order now, lowest precedence first: the named environment variables, the trigger arguments, the TOML file they name, and on the HTTP trigger the request body. The file overrides the trigger arguments instead of replacing them, so an argument it does not set still applies. The HTTP trigger gains arguments and a config file of its own, holding the defaults each request overrides, and an http_args_config block so Explorer offers them. config_file_path stays a trigger argument and the request body still refuses it. The cross-setting checks and the derived windows move out of the entry points into prepare_scheduled_config and prepare_http_config, so each entry point opens with load_config and one guard clause. The endpoint's responses are unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Configuration was loaded in a _load_config helper that called load_config twice: once over the trigger arguments alone, then again with the TOML file on top, keeping the first result when the second raised. A config file that could not be read, was not named .toml, or held an invalid value was logged and skipped, and the run continued on the inline arguments. Validating the arguments alone first also meant the file was never opened when that pass failed, so a setting marked required and supplied only by the file would have been reported missing. Load both layers in one call from process_scheduled_call, matching prophet_forecasting and geo_enrichment: one except clause, a Configuration error log line, and a Config result rather than a None sentinel. An unusable config file now stops the run instead of falling back. Drop the lower-casing of the merged keys, which the allowlist already guarantees, and name the constants for what they hold. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Move the plugin onto the pattern the other plugins took up for utils 0.4.0: declarative validators, a KeySpec naming what a layer may set, and the layers composed in the entry point. - load_plugin_config gives way to load_config over parse_trigger_args and parse_toml, each narrowed by a KeySpec built from the validator names - SETTING_VALIDATORS, PRESET_VALIDATORS and MANUAL_VALIDATORS replace the hand-rolled defaults, casts and checks; prepare_config keeps the refusals whose message has to name a second setting - the frozen Config dataclass gives way to the utils Config, and ConfigError to the ValueError the validators already raise - drop two dead except clauses: 0.4.0 turns every source failure into ValueError, so neither FileNotFoundError nor TOMLDecodeError could fire, and the tomllib import went with them - drop the module-level import shim for the utils package, which the validator tables cannot be built without config_file_path now layers with the inline trigger arguments, the file winning, rather than being mutually exclusive with them. A configuration that was rejected before now runs; nothing that worked before changes. Keys are no longer lower-cased before they are matched, so a file spelling a key FC2 no longer reaches fc2. Folding is what 0.4.0 dropped deliberately, and it is also what an allowlist cannot see past. Checked by resolving 263722 configurations through both the old and the new code and comparing every setting and every message: the mutual exclusivity above is the only difference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
prophet_forecasting, system_metrics and signal_filter take an environment layer underneath the layers they already had, so a setting can be held in the environment rather than written into a trigger or a file. - each plugin reads INFLUXDB3_<PLUGIN_NAME>_<SETTING>, built from the names it already validates; env_spec strips the prefix again, so a variable merges per key with the same setting from any other layer - the environment is the lowest layer: a trigger argument overrides it, the TOML file overrides both, and on prophet's HTTP trigger the request body overrides them all - config_file_path comes from INFLUXDB3_<PLUGIN_NAME>_CONFIG_FILE_PATH as well as from the trigger arguments, the argument winning. It names a layer rather than setting a value, so it stays out of the merged config - prophet's scheduled spec also covers the notifier keys it passes on (senders, the webhook URLs, the Twilio credentials), which have no validator of their own; influxdb3_auth_token keeps INFLUXDB3_AUTH_TOKEN rather than gaining a second spelling Nothing changes for a deployment that sets none of the new variables: every layer that was read before is still read, in the same order. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The plugin takes an environment layer underneath the layers it already had, as prophet_forecasting, system_metrics and signal_filter did, so a setting can be held in the environment rather than written into a trigger or a file. - INFLUXDB3_GEO_ENRICHMENT_<SETTING>, built from the names each trigger validates: WRITES_ENV covers the settings, REQUEST_ENV those plus the backfill fields the HTTP trigger reads. env_spec strips the prefix again, so a variable merges per key with the same setting from any other layer - the environment is the lowest layer: a trigger argument overrides it, the TOML file overrides both, and the request body overrides them all - config_file_path comes from INFLUXDB3_GEO_ENRICHMENT_CONFIG_FILE_PATH as well as from the trigger arguments, the argument winning. The body still cannot name it: the path chooses a layer rather than setting a value, and that stays the operator's decision Nothing changes for a deployment that sets none of the new variables: every layer that was read before is still read, in the same order. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The HTTP trigger reads two more layers above the body, so a backfill can
be steered from a curl one-liner or a client that can only add a header:
env -> args -> TOML -> body -> headers -> query parameters
- headers are spelled X-Influxdb3-Geo-Enrichment-<SETTING>, underscores
written as hyphens and the name renamed back onto the setting key;
matched regardless of casing, as RFC 9110 asks
- query parameters are spelled exactly like the setting, the query string
belonging to this endpoint alone
- one REQUEST_KEYS list now feeds the environment, body, header and query
specs, replacing the allowlist the body rebuilt inline
- a header this plugin does not ask for is dropped, since a client sends
headers of its own on every request; an unknown query parameter is a
400, as an unknown body field already was
- config_file_path stays unreachable from a request: the body and the
query string refuse it, a header spelling it is dropped
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The HTTP trigger reads two more layers above the body, as geo_enrichment
does:
env -> args -> TOML -> body -> headers -> query parameters
- headers are spelled X-Influxdb3-Prophet-Forecasting-<SETTING>,
underscores written as hyphens and the name renamed back onto the
setting key; matched regardless of casing, as RFC 9110 asks
- query parameters are spelled exactly like the setting
- one HTTP_KEYS list now feeds the environment, body, header and query
specs, replacing the two places that rebuilt the validator names
- a header this plugin does not ask for is dropped; an unknown query
parameter is refused and named in the response, as an unknown body
field already was
- config_file_path stays unreachable from a request
query_parameters and request_headers were documented as unused; they now
say what they set.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three things, all downstream of utils 0.4.0: