Looking for feedback: adds interceptor lifecycle hook

[skrawcz]

This proposes a new hook to allow one to remotely push execution of a Burr Action.

For example, if one wants to selectively push remote execution of an action to say Ray,
then one can now build an interceptor.

This also introduces companion hooks that would run pre & post on the remote to mirror
what Burr has today - -I thought it would be simpler to not try to reuse those hooks, and
instead make it explicit as to what is going on if you wanted to add something similar.

See tests for examples, but open to feedback here.

Note: we'd need to think through how this plays with parallelism functionality we have.
E.g. currently interceptors aren't propagated to sub applications...

Changes

• adds to internal hooks to intercept an action and remotely execute it
• adds ray example

How I tested this

• NEEDS EXTENSIVE TESTING
• Test sync
• Test async
• Test async streaming
• Test sync streaming
• I ran some ray examples
• need to write another interceptor for another backend, e.g. temporal to feel it out.

Notes

This change needs to have some thought and discussion.

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[github-actions]

A preview of is uploaded and can be seen here:

✨ https://burr.dagworks.io/pull/602 ✨

Changes may take a few minutes to propagate. Since this is a preview of production, content with draft: true will not be rendered. The source is here: https://github.com/apache/burr/tree/gh-pages/pull/602/

[goutamk09]

@skrawcz Thanks for opening this — I really like the direction of making remote execution explicit via lifecycle hooks.

Before diving into design feedback, I’m trying to fully understand the current execution flow vs the new interception path. A few things I’m exploring:

• Where in the action execution pipeline the new hook takes over execution
• How this behaves across sync / async / streaming paths
• Why tests are failing on 3.11 and 3.12 but not 3.9 / 3.10
• How this might interact with sub-applications and parallel execution (as noted in the PR)

I’ll follow up with more concrete observations once I’ve traced the execution path locally.

[goutamk09]

Hey @skrawcz
I’ve run the interceptor-specific integration tests locally on Python 3.11 and they are passing (sync, async, streaming, worker hooks).

Running the full test suite locally shows failures related to missing optional integration dependencies (redis, mongodb, asyncpg, langchain, etc.), not interceptor behavior.

From what I can see so far, the interceptor lifecycle implementation itself appears stable under 3.11.

I’m continuing to look into what might be causing the CI 3.11/3.12 failures — especially around async execution paths or example validation.