[connector/routing] Use inferred contexts

.chloggen/38080-connector-routing-context.yaml

@@ -0,0 +1,31 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the component, or a single word describing the area of concern, (e.g. receiver/filelog)
+component: connector/routing
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Add OTTL context inference support to routing connector.
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [38080]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: |
+  The routing connector now supports OTTL context inference, allowing users to write clearer routing conditions using 
+  context-qualified paths. Instead of relying on implicit context resolution, users can explicitly specify which 
+  context's attributes they want to access (e.g., `resource.attributes["env"]` or `span.attributes["http.method"]`). 
+  Unqualified paths like `attributes["key"]` continue to work and default to the resource context for backward compatibility. 
+
+# If your change doesn't affect end users or the exported elements of any package,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user]

.chloggen/44762-routing-dupes.yaml

@@ -0,0 +1,30 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: bug_fix
+
+# The name of the component, or a single word describing the area of concern, (e.g. receiver/filelog)
+component: connector/routing
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Fix duplicate routing table entry handling to correctly ignore duplicates instead of overwriting the original route
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [44762]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: |
+  Previously, when duplicate routing table entries were encountered, the warning message indicated that the duplicate 
+  would be ignored, but in fact the original entry was being overwritten by the duplicate. 
+  This fix ensures that duplicates are properly ignored and the original route's consumer is preserved.
+
+# If your change doesn't affect end users or the exported elements of any package,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user]

connector/routingconnector/README.md

@@ -35,16 +35,48 @@ If you are not already familiar with connectors, you may find it helpful to firs
 The following settings are available:
 
 - `table (required)`: the routing table for this connector.
-- `table.context (optional, default: resource)`: the [OTTL Context] in which the statement will be evaluated. Currently, only `resource`, `span`, `metric`, `datapoint`, `log`, and `request` are supported.
-- `table.statement`: the routing condition provided as the [OTTL] statement. Required if `table.condition` is not provided. May not be used for `request` context.
+- `table.context (optional, default: resource)`: the [OTTL Context] in which the statement will be evaluated. Currently, only `resource`, `span`, `metric`, `datapoint`, `log`, and `request` are supported. If not specified, the context can be inferred from context-qualified paths in the statement/condition (see [Context Inference](#context-inference)).
+- `table.statement`: the routing condition provided as the [OTTL] statement. Required if `table.condition` is not provided. May not be used for `request` context. 
 - `table.condition`: the routing condition provided as the [OTTL] condition. Required if `table.statement` is not provided. Required for `request` context.
 - `table.pipelines (required)`: the list of pipelines to use when the routing condition is met.
 - `default_pipelines (optional)`: contains the list of pipelines to use when a record does not meet any of specified conditions.
 - `error_mode (optional)`: determines how errors returned from OTTL statements are handled. Valid values are `propagate`, `ignore` and `silent`. If `ignore` or `silent` is used and a statement's condition has an error then the payload will be routed to the default pipelines. When `silent` is used the error is not logged. If not supplied, `propagate` is used.
 
+### Context Inference
+
+The routing connector supports OTTL context inference, allowing you to write clearer routing conditions using context-qualified paths. You can explicitly specify which context's attributes you want to access.
+
+For example, instead of writing:
+
+```yaml
+# Relies on the default context of 'resource'
+condition: attributes["env"] == "prod"
+```
+
+You can write:
+
+```yaml
+condition: resource.attributes["env"] == "prod"
+```
+
+This makes it immediately clear that you're accessing the resource's attributes, not log record attributes or span attributes.
+
+**Supported context-qualified paths:**
+
+| Context | Path prefix | Example |
+|---------|-------------|---------|
+| Resource | `resource.` | `resource.attributes["service.name"]` |
+| Span | `span.` | `span.attributes["http.method"]` |
+| Log | `log.` | `log.body`, `log.attributes["level"]` |
+| Metric | `metric.` | `metric.name` |
+| Datapoint | `datapoint.` | `datapoint.attributes["host"]` |
+
+**Backward compatibility:** Unqualified paths like `attributes["env"]` continue to work and default to the `resource` context for backward compatibility.
+
 ### Limitations
 
 - The `request` context requires use of the `condition` setting, and relies on a very limited grammar. Conditions must be in the form of `request["key"] == "value"` or `request["key"] != "value"`. (In the future, this grammar may be expanded to support more complex conditions.)
+- When using context inference without an explicit `context` field, the inferred context must be compatible with the pipeline signal type (e.g., `span` context can only be used in traces pipelines).
 
 ### Supported [OTTL] functions
 
@@ -62,7 +94,50 @@ The full list of settings exposed for this connector are documented in [config.g
 
 ## Examples
 
-Route logs based on tenant:
+### Route traces using context-qualified paths
+
+This example demonstrates context inference with explicit context-qualified paths:
+
+```yaml
+receivers:
+  otlp:
+
+exporters:
+  file/prod:
+    path: ./prod.json
+  file/debug:
+    path: ./debug.json
+  file/other:
+    path: ./other.json
+
+connectors:
+  routing:
+    default_pipelines: [traces/other]
+    table:
+      # Using resource context with qualified path - routes based on resource attributes
+      - condition: resource.attributes["deployment.environment"] == "production"
+        pipelines: [traces/prod]
+      # Using span context with qualified path - routes based on span attributes
+      - condition: span.attributes["debug"] == true
+        pipelines: [traces/debug]
+
+service:
+  pipelines:
+    traces/in:
+      receivers: [otlp]
+      exporters: [routing]
+    traces/prod:
+      receivers: [routing]
+      exporters: [file/prod]
+    traces/debug:
+      receivers: [routing]
+      exporters: [file/debug]
+    traces/other:
+      receivers: [routing]
+      exporters: [file/other]
+```
+
+### Route logs based on tenant
 
 ```yaml
 receivers: