feat: adds plugin_span_filters to config json and helm charts - #4201
Conversation
|
Caution Review failedPull request was closed or merged during review Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughGeneralizes the OTEL-only plugin span filter schema into a shared definition, wires ChangesPlugin Span Filtering Generalization and BigQuery Plugin Addition
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
e8c3643 to
1d37af0
Compare
Confidence Score: 5/5Schema-only and Helm-template change; no Go runtime code touched; all previous reviewer concerns have been addressed. The PR touches only JSON schema files, Helm templates, and values files. The three issues flagged in previous review threads — project_id silently dropped, missing required in the Helm schema, and numeric fields being dropped for a zero value — are all explicitly addressed: a Helm fail guard fires at deploy time when project_id is absent, required: ["project_id"] is present in both schema files, and flush_interval_seconds/buffer_size correctly use hasKey. No Go code is changed, so there are no runtime regressions to evaluate. No files require special attention. Important Files Changed
Reviews (5): Last reviewed commit: "feat: adds plugin_span_filters to config..." | Re-trigger Greptile |
There was a problem hiding this comment.
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)
helm-charts/bifrost/values.schema.json (1)
903-966:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd conditional
requiredvalidation for BigQuery core configuration fields.BigQuery cannot operate without
project_id,dataset_id, andtable_id, but the schema does not enforce these as required. Other plugins (e.g.,semanticCacheat lines 822-835) useif/thenconditionals to require essential fields whenenabled: true.Add a validation guard to ensure these core fields are present when the BigQuery plugin is enabled.
🛡️ Proposed validation guard
"bigquery": { "type": "object", "properties": { "enabled": { "type": "boolean" }, "version": { "type": "integer", "minimum": 1 }, "config": { ... } - } + }, + "if": { + "properties": { + "enabled": { + "const": true + } + } + }, + "then": { + "properties": { + "config": { + "required": ["project_id", "dataset_id", "table_id"] + } + } + } },🤖 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 `@helm-charts/bifrost/values.schema.json` around lines 903 - 966, The BigQuery schema block for "bigquery" is missing an if/then guard to require core config fields when enabled; update the "bigquery" object to add an "if" that checks { "properties": { "enabled": { "const": true } } } and a corresponding "then" that enforces "config" -> "required": ["project_id","dataset_id","table_id"] (and/or require "config" itself) similar to the existing semanticCache pattern; reference the "bigquery" schema, its "enabled" property and the "config" properties (project_id, dataset_id, table_id) when adding this conditional validation so those fields are mandatory only when bigquery.enabled is true.
🤖 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 `@helm-charts/bifrost/values.schema.json`:
- Around line 928-940: The current schema for service_account_key allows value,
env_var and from_env to coexist; change the inner object schema so the object
enforces mutual exclusivity by replacing the "properties" block with a oneOf
that defines two clear alternatives: one alternative requires ["value"] (type:
string) and disallows other properties, the other requires
["env_var","from_env"] (env_var: string, from_env: boolean) and disallows other
properties; keep the outer anyOf that accepts a plain string or this new
oneOf-object to ensure either a direct credential or environment indirection is
supplied but not both.
---
Outside diff comments:
In `@helm-charts/bifrost/values.schema.json`:
- Around line 903-966: The BigQuery schema block for "bigquery" is missing an
if/then guard to require core config fields when enabled; update the "bigquery"
object to add an "if" that checks { "properties": { "enabled": { "const": true }
} } and a corresponding "then" that enforces "config" -> "required":
["project_id","dataset_id","table_id"] (and/or require "config" itself) similar
to the existing semanticCache pattern; reference the "bigquery" schema, its
"enabled" property and the "config" properties (project_id, dataset_id,
table_id) when adding this conditional validation so those fields are mandatory
only when bigquery.enabled is true.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0f23d8d9-b007-46d2-81b5-8eece4dcb5db
📒 Files selected for processing (5)
helm-charts/bifrost/README.mdhelm-charts/bifrost/templates/_helpers.tplhelm-charts/bifrost/values.schema.jsonhelm-charts/bifrost/values.yamltransports/config.schema.json
7e12811 to
7473d46
Compare
1d37af0 to
45d25de
Compare
7473d46 to
a02e997
Compare
45d25de to
1931de3
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@helm-charts/bifrost/README.md`:
- Line 25: Update the changelog/README to explicitly warn external schema
consumers that the internal JSON Schema $defs identifier otelPluginSpanFilter
(and any snake_case variant otel_plugin_span_filter) was renamed to
pluginSpanFilter; although the Helm chart's user-facing config key
plugin_span_filter is unchanged, any external tooling or configs that reference
the old $defs name must be updated to reference pluginSpanFilter to avoid
breakage. Ensure the note mentions all affected plugin configs (OTEL, Datadog,
BigQuery) and that this is an internal schema-definition rename only for Helm
users but a breaking change for external $defs consumers.
In `@helm-charts/bifrost/values.yaml`:
- Around line 539-541: Add an inline security warning comment next to the
custom_labels and request_headers entries (referencing the custom_labels and
request_headers keys) that explicitly warns users not to place secrets or
credential material (e.g., service_account_key, tokens, passwords, private keys)
in those fields because they may be logged or exported to external systems; keep
the comment concise and placed immediately above or beside the existing
custom_labels/request_headers lines so it's visible when editing values.yaml.
In `@transports/config.schema.json`:
- Around line 1707-1709: Update the helm chart README to stop referencing the
removed OTEL schema name `otel_plugin_span_filter` /
`"$defs/otel_plugin_span_filter"` and instead reference the shared schema
`plugin_span_filter` (`$defs/plugin_span_filter`); search for any occurrences of
`otel_plugin_span_filter`, `"$defs/otel_plugin_span_filter"`, or wording that
implies a separate OTEL-specific schema in `helm-charts/bifrost/README.md` and
replace them with `plugin_span_filter` and `"$defs/plugin_span_filter"`,
updating any explanatory text so it correctly describes using the shared
`plugin_span_filter` shape.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b22b66d0-f2bb-47ce-92e7-69bfeb30431e
📒 Files selected for processing (5)
helm-charts/bifrost/README.mdhelm-charts/bifrost/templates/_helpers.tplhelm-charts/bifrost/values.schema.jsonhelm-charts/bifrost/values.yamltransports/config.schema.json
1931de3 to
7350823
Compare
Merge activity
|
The base branch was changed.
7350823 to
3e5da32
Compare
## Summary
Extends `plugin_span_filter` support to the Datadog observability connector and introduces a new BigQuery traces connector, while renaming the shared `otelPluginSpanFilter` / `otel_plugin_span_filter` schema definition to the more generic `pluginSpanFilter` / `plugin_span_filter` so it can be reused across all observability connectors.
## Changes
- Added `plugin_span_filter` support to the Datadog plugin in both the Helm chart template (`_helpers.tpl`) and its schema/values definitions, matching the existing pattern used by OTEL connectors.
- Renamed the `otelPluginSpanFilter` / `otel_plugin_span_filter` schema `$defs` entry to `pluginSpanFilter` / `plugin_span_filter` in both `values.schema.json` and `transports/config.schema.json`, and updated all `$ref` usages accordingly. The description was also updated to clarify that the filter applies to any observability connector, not just OTEL.
- Added a full JSON schema definition for a new `bigquery` observability connector in `transports/config.schema.json`, including fields for `project_id`, `dataset_id`, `table_id`, `location`, `service_account_key` (with ADC fallback), `flush_interval_seconds`, `buffer_size`, `custom_labels`, `disable_content_logging`, `request_headers`, and `plugin_span_filter`.
- Added the `bigquery` plugin to the Helm chart (`values.yaml`, `values.schema.json`, and `_helpers.tpl`) with the same `version` validation guard used by other built-in plugins.
- Added commented-out `plugin_span_filter` examples to `values.yaml` for both the Datadog and BigQuery plugins to aid discoverability.
## Type of change
- [ ] Bug fix
- [x] Feature
- [x] Refactor
- [ ] Documentation
- [ ] Chore/CI
## Affected areas
- [ ] Core (Go)
- [x] Transports (HTTP)
- [ ] Providers/Integrations
- [x] Plugins
- [ ] UI (React)
- [ ] Docs
## How to test
1. Deploy the Helm chart with a Datadog plugin config that includes `plugin_span_filter`:
```yaml
bifrost:
plugins:
datadog:
config:
plugin_span_filter:
mode: "exclude"
plugins: ["logging"]
```
Verify the rendered manifest includes `plugin_span_filter` in the Datadog plugin config.
2. Deploy the Helm chart with the BigQuery plugin enabled:
```yaml
bifrost:
plugins:
bigquery:
enabled: true
version: 1
config:
project_id: "my-gcp-project"
dataset_id: "bifrost_traces"
table_id: "traces"
```
Verify the rendered manifest includes the BigQuery plugin config with the expected fields.
3. Validate `transports/config.schema.json` against a BigQuery connector config:
```json
{
"name": "bigquery",
"config": {
"project_id": "my-gcp-project",
"plugin_span_filter": { "mode": "include", "plugins": ["auth"] }
}
}
```
4. Confirm that no dangling `$ref` entries referencing the old `otelPluginSpanFilter` / `otel_plugin_span_filter` names remain in either schema file.
## Breaking changes
- [x] Yes
- [ ] No
The `otelPluginSpanFilter` / `otel_plugin_span_filter` `$defs` keys have been renamed to `pluginSpanFilter` / `plugin_span_filter`. Any external tooling or configs that reference these definition names directly will need to be updated.
## Related issues
## Security considerations
The BigQuery connector schema supports `service_account_key` via an environment variable reference (`env.MY_VAR`) or Application Default Credentials, avoiding the need to embed raw credentials in config files. Care should be taken to ensure service account keys are not logged or exposed through the `custom_labels` or `request_headers` fields.
## Checklist
- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] I added/updated tests where appropriate
- [ ] I updated documentation where needed
- [ ] I verified builds succeed (Go and UI)
- [ ] I verified the CI pipeline passes locally if applicable
…q#4201) ## Summary Extends `plugin_span_filter` support to the Datadog observability connector and introduces a new BigQuery traces connector, while renaming the shared `otelPluginSpanFilter` / `otel_plugin_span_filter` schema definition to the more generic `pluginSpanFilter` / `plugin_span_filter` so it can be reused across all observability connectors. ## Changes - Added `plugin_span_filter` support to the Datadog plugin in both the Helm chart template (`_helpers.tpl`) and its schema/values definitions, matching the existing pattern used by OTEL connectors. - Renamed the `otelPluginSpanFilter` / `otel_plugin_span_filter` schema `$defs` entry to `pluginSpanFilter` / `plugin_span_filter` in both `values.schema.json` and `transports/config.schema.json`, and updated all `$ref` usages accordingly. The description was also updated to clarify that the filter applies to any observability connector, not just OTEL. - Added a full JSON schema definition for a new `bigquery` observability connector in `transports/config.schema.json`, including fields for `project_id`, `dataset_id`, `table_id`, `location`, `service_account_key` (with ADC fallback), `flush_interval_seconds`, `buffer_size`, `custom_labels`, `disable_content_logging`, `request_headers`, and `plugin_span_filter`. - Added the `bigquery` plugin to the Helm chart (`values.yaml`, `values.schema.json`, and `_helpers.tpl`) with the same `version` validation guard used by other built-in plugins. - Added commented-out `plugin_span_filter` examples to `values.yaml` for both the Datadog and BigQuery plugins to aid discoverability. ## Type of change - [ ] Bug fix - [x] Feature - [x] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [x] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs ## How to test 1. Deploy the Helm chart with a Datadog plugin config that includes `plugin_span_filter`: ```yaml bifrost: plugins: datadog: config: plugin_span_filter: mode: "exclude" plugins: ["logging"] ``` Verify the rendered manifest includes `plugin_span_filter` in the Datadog plugin config. 2. Deploy the Helm chart with the BigQuery plugin enabled: ```yaml bifrost: plugins: bigquery: enabled: true version: 1 config: project_id: "my-gcp-project" dataset_id: "bifrost_traces" table_id: "traces" ``` Verify the rendered manifest includes the BigQuery plugin config with the expected fields. 3. Validate `transports/config.schema.json` against a BigQuery connector config: ```json { "name": "bigquery", "config": { "project_id": "my-gcp-project", "plugin_span_filter": { "mode": "include", "plugins": ["auth"] } } } ``` 4. Confirm that no dangling `$ref` entries referencing the old `otelPluginSpanFilter` / `otel_plugin_span_filter` names remain in either schema file. ## Breaking changes - [x] Yes - [ ] No The `otelPluginSpanFilter` / `otel_plugin_span_filter` `$defs` keys have been renamed to `pluginSpanFilter` / `plugin_span_filter`. Any external tooling or configs that reference these definition names directly will need to be updated. ## Related issues ## Security considerations The BigQuery connector schema supports `service_account_key` via an environment variable reference (`env.MY_VAR`) or Application Default Credentials, avoiding the need to embed raw credentials in config files. Care should be taken to ensure service account keys are not logged or exposed through the `custom_labels` or `request_headers` fields. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [ ] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
…q#4201) ## Summary Extends `plugin_span_filter` support to the Datadog observability connector and introduces a new BigQuery traces connector, while renaming the shared `otelPluginSpanFilter` / `otel_plugin_span_filter` schema definition to the more generic `pluginSpanFilter` / `plugin_span_filter` so it can be reused across all observability connectors. ## Changes - Added `plugin_span_filter` support to the Datadog plugin in both the Helm chart template (`_helpers.tpl`) and its schema/values definitions, matching the existing pattern used by OTEL connectors. - Renamed the `otelPluginSpanFilter` / `otel_plugin_span_filter` schema `$defs` entry to `pluginSpanFilter` / `plugin_span_filter` in both `values.schema.json` and `transports/config.schema.json`, and updated all `$ref` usages accordingly. The description was also updated to clarify that the filter applies to any observability connector, not just OTEL. - Added a full JSON schema definition for a new `bigquery` observability connector in `transports/config.schema.json`, including fields for `project_id`, `dataset_id`, `table_id`, `location`, `service_account_key` (with ADC fallback), `flush_interval_seconds`, `buffer_size`, `custom_labels`, `disable_content_logging`, `request_headers`, and `plugin_span_filter`. - Added the `bigquery` plugin to the Helm chart (`values.yaml`, `values.schema.json`, and `_helpers.tpl`) with the same `version` validation guard used by other built-in plugins. - Added commented-out `plugin_span_filter` examples to `values.yaml` for both the Datadog and BigQuery plugins to aid discoverability. ## Type of change - [ ] Bug fix - [x] Feature - [x] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [x] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs ## How to test 1. Deploy the Helm chart with a Datadog plugin config that includes `plugin_span_filter`: ```yaml bifrost: plugins: datadog: config: plugin_span_filter: mode: "exclude" plugins: ["logging"] ``` Verify the rendered manifest includes `plugin_span_filter` in the Datadog plugin config. 2. Deploy the Helm chart with the BigQuery plugin enabled: ```yaml bifrost: plugins: bigquery: enabled: true version: 1 config: project_id: "my-gcp-project" dataset_id: "bifrost_traces" table_id: "traces" ``` Verify the rendered manifest includes the BigQuery plugin config with the expected fields. 3. Validate `transports/config.schema.json` against a BigQuery connector config: ```json { "name": "bigquery", "config": { "project_id": "my-gcp-project", "plugin_span_filter": { "mode": "include", "plugins": ["auth"] } } } ``` 4. Confirm that no dangling `$ref` entries referencing the old `otelPluginSpanFilter` / `otel_plugin_span_filter` names remain in either schema file. ## Breaking changes - [x] Yes - [ ] No The `otelPluginSpanFilter` / `otel_plugin_span_filter` `$defs` keys have been renamed to `pluginSpanFilter` / `plugin_span_filter`. Any external tooling or configs that reference these definition names directly will need to be updated. ## Related issues ## Security considerations The BigQuery connector schema supports `service_account_key` via an environment variable reference (`env.MY_VAR`) or Application Default Credentials, avoiding the need to embed raw credentials in config files. Care should be taken to ensure service account keys are not logged or exposed through the `custom_labels` or `request_headers` fields. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [ ] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable

Summary
Extends
plugin_span_filtersupport to the Datadog observability connector and introduces a new BigQuery traces connector, while renaming the sharedotelPluginSpanFilter/otel_plugin_span_filterschema definition to the more genericpluginSpanFilter/plugin_span_filterso it can be reused across all observability connectors.Changes
plugin_span_filtersupport to the Datadog plugin in both the Helm chart template (_helpers.tpl) and its schema/values definitions, matching the existing pattern used by OTEL connectors.otelPluginSpanFilter/otel_plugin_span_filterschema$defsentry topluginSpanFilter/plugin_span_filterin bothvalues.schema.jsonandtransports/config.schema.json, and updated all$refusages accordingly. The description was also updated to clarify that the filter applies to any observability connector, not just OTEL.bigqueryobservability connector intransports/config.schema.json, including fields forproject_id,dataset_id,table_id,location,service_account_key(with ADC fallback),flush_interval_seconds,buffer_size,custom_labels,disable_content_logging,request_headers, andplugin_span_filter.bigqueryplugin to the Helm chart (values.yaml,values.schema.json, and_helpers.tpl) with the sameversionvalidation guard used by other built-in plugins.plugin_span_filterexamples tovalues.yamlfor both the Datadog and BigQuery plugins to aid discoverability.Type of change
Affected areas
How to test
Deploy the Helm chart with a Datadog plugin config that includes
plugin_span_filter:Verify the rendered manifest includes
plugin_span_filterin the Datadog plugin config.Deploy the Helm chart with the BigQuery plugin enabled:
Verify the rendered manifest includes the BigQuery plugin config with the expected fields.
Validate
transports/config.schema.jsonagainst a BigQuery connector config:{ "name": "bigquery", "config": { "project_id": "my-gcp-project", "plugin_span_filter": { "mode": "include", "plugins": ["auth"] } } }Confirm that no dangling
$refentries referencing the oldotelPluginSpanFilter/otel_plugin_span_filternames remain in either schema file.Breaking changes
The
otelPluginSpanFilter/otel_plugin_span_filter$defskeys have been renamed topluginSpanFilter/plugin_span_filter. Any external tooling or configs that reference these definition names directly will need to be updated.Related issues
Security considerations
The BigQuery connector schema supports
service_account_keyvia an environment variable reference (env.MY_VAR) or Application Default Credentials, avoiding the need to embed raw credentials in config files. Care should be taken to ensure service account keys are not logged or exposed through thecustom_labelsorrequest_headersfields.Checklist
docs/contributing/README.mdand followed the guidelinesSummary by CodeRabbit
New Features
plugin_span_filteroption to Datadog plugin to control which spans are exported.Documentation