fix: refactor runtime execute

[cristipufu]

Description

Refactors the runtime execution flow to simplify input/output handling, the suspension/resume support, and streamline streaming execution, in preparation for debug and conversational agents.

• Replaces LangGraphInputProcessor/LangGraphOutputProcessor classes with functional utilities
• Refactors suspend detection (static/dynamic interrupts)
• Centralizes graph config building and streaming execution logic

Development Package

• Add this package as a dependency in your pyproject.toml:

[project]
dependencies = [
  # Exact version:
  "uipath-langchain==0.0.141.dev1002270786",

  # Any version from PR
  "uipath-langchain>=0.0.141.dev1002270000,<0.0.141.dev1002280000"
]

[[tool.uv.index]]
name = "testpypi"
url = "https://test.pypi.org/simple/"
publish-url = "https://test.pypi.org/legacy/"
explicit = true

[tool.uv.sources]
uipath-langchain = { index = "testpypi" }

[akshaylive]

This line closes the memory object once it goes out of scope so I wouldn't recommend caching it. It's better to just instantiate it during object construction

self.context.memory = AsyncSqliteSaver.from_conn_string(self.state_file_path)

Then, in the cleanup method of LangGraphRuntime, we will need to invoke self.context.memory.close() or something along these lines. This will also fix the parallel-evaluations issue that was reported last week.

[cristipufu]

removed the caching. Yes, the idea is to use the memory externally provided, otherwise create a new local scope

[akshaylive]

I see what you mean.

I was thinking of getting removing memory from UiPathRuntimeContext and moving it to the runtime object. IMO this will simplify how the cache objects are created. I currently don't see why the caller would invoke execute with different memory objects.

Since the cache is removed, the concern of maintaining the cache object is moved to the caller. If a called does not provide a cache object, this line will create new objects for every single execution. Caching the sqlite object is a good idea. However, IMO we should not be closing it unless the runtime exists (i.e; via cleanup).

We could change this later too and decouple it from this PR.

[akshaylive]

Nit: should this be logger.verbose?

[cristipufu]

doesn't seem like a built-in method

[akshaylive]

Sorry, I meant debug. Basically, my concern is that event may contain sensitive information, and should be only shown during dev time.