error_source_path returns null when called from the fallback output processor

Hi,

Description

In certain situations, calling the error_source_path() function within a processor returns null even though it should provide the path to the component that generated the error. This behavior depends on the pipeline layout and the processor location.

Expected behavior

The error_source_path() function should always return the correct path relevant to where the error originated, similar to how error_source_label() and error_source_name() operate.
Actual behavior

In some cases, error_source_path() returns null.

Example 1 — Works as expected

logger:
  level: error

input:
  generate:
    count: 1
    mapping: root = null

pipeline:
  processors:
    - resource: raise
    - resource: error_processor

output:
  resource: stdout_writer

processor_resources:
  - label: raise
    mapping: |
      #!blobl
      root = throw("fatal error")
  - label: error_processor
    mapping: |
      #!blobl
      root.error.label = error_source_label()
      root.error.name = error_source_name()
      root.error.path = error_source_path()

output_resources:
  - label: stdout_writer
    stdout: {}

Result:

❯ rpk connect run test_2.yaml
ERRO[2025-10-20T20:15:26+07:00] failed assignment (line 2): fatal error       @service=redpanda-connect label=raise path=root.processor_resources
{"error":{"label":"raise","name":"mapping","path":"processor_resources"}}

Example 2 — Incorrect behavior

logger:
  level: error

input:
  generate:
    count: 1
    mapping: root = null

output:
  resource: stdout_writer

processor_resources:
  - label: error_processor
    mapping: |
      #!blobl
      root.error.label = error_source_label()
      root.error.name = error_source_name()
      root.error.path = error_source_path()

output_resources:
  - label: error_writer
    stdout: {}
    processors:
      - resource: error_processor

  - label: db_writer
    sql_raw:
      driver: postgres
      dsn: postgresql://127.0.0.1:5432
      query: SELECT 1

  - label: stdout_writer
    fallback:
      - resource: db_writer
      - resource: error_writer

Result:

❯ rpk connect run test_3.yaml
ERRO[2025-10-20T20:15:22+07:00] Failed to send message to sql_raw: failed to run query: dial tcp 127.0.0.1:5432: connect: connection refused  @service=redpanda-connect label=db_writer path=root.output_resources
{"error":{"label":null,"name":null,"path":null}}

Expected output:

{"error":{"label":"db_writer","name":"sql_raw","path":"output_resources"}}

Expectation

error_source_path() should always return the relevant component path, regardless of the processor location and pipeline structure.

Addition info

It seems the issue appears when using processors inside fallback, while inside the pipeline the path is set correctly.

❯ rpk connect --version
Version: 4.66.1
Date: 2025-10-03T12:56:41Z
❯ uname -r
6.17.3-zen2-1.1-zen

Regards.

Start by running the two rpk connect run YAML reproductions and tracing error_source_path() through processors nested in fallback, especially the output_resources and processor_resources paths. Done means the fallback example reports db_writer, sql_raw, and output_resources instead of null, while the working example remains correct.