[Feature Request]: Add the possibility to add a JSON object at the endpoint to run tasks

[puchy22]

Feature Description

Enable the API to return task results as Any or JSON objects instead of limiting them to plain strings.

Reason

Currently, the result of a Workflow can be of any type, as specified in the result parameter of a Stop event. However, the API only supports returning results as strings. Expanding this to include JSON objects would enhance the API's ability to represent complex data structures more accurately. JSON support is particularly valuable because, while casting simple types like integers from strings is straightforward, handling more complex structures like dictionaries becomes cumbersome and error-prone when parsing strings, especially with multiple keys and values.

Example

Suppose a Workflow returns the following Stop event:

return StopEvent(
    result={
        "key-1": "value-1",
        "key-2": {
            "nested-key": 42,
            "nested-list": [1, 2, 3]
        }
    }
)

Currently, the API would return this as a string like:
"{'key-1': 'value-1', 'key-2': {'nested-key': 42, 'nested-list': [1, 2, 3]}}"

To use this output, a consumer of the API would need to parse it back into a dictionary, which can be error-prone and inefficient, especially for deeply nested structures. With the proposed change, the API would return a proper JSON object like:

{
    "key-1": "value-1",
    "key-2": {
        "nested-key": 42,
        "nested-list": [1, 2, 3]
    }
}

This structured format eliminates the need for manual parsing and ensures compatibility with modern HTTP consumers.

Value of Feature

This feature simplifies the consumption of API results by allowing structured data to be returned directly. For instance, when a Workflow processes data and produces structured output (e.g., dictionaries), users won't need to manually parse a string representation, which might be infeasible for complex data. By supporting JSON objects, the API becomes more user-friendly, particularly for developers integrating workflows with HTTP-based systems.

[Tehsmash]

I would also like to see better support here;

For reference I played around a bit with this locally, and I changed my workflow to return a JSON string using a pydantic encoder. We could build this into llama deploy by changing https://github.com/run-llama/llama_deploy/blob/main/llama_deploy/services/workflow.py#L347 to use pydantic to_json to json encode the result. However, this will still result in the result being a correctly formatted json encoded string which isn't too hard for consumers to decode, it's certainly better than just "str(...)" casting the result.
Clients can use model_validate_json to load result back into an object to see the result as an object.

[masci]

First of all, this all makes a lot of sense, thank you for starting the conversation!

I think there's room to introduce something at the "api server" level - if we find a way to tell LlamaDeploy what's the expected return value for a deployment task, the underlying workflow could still return a string representation of the payload that we could de-serialize within the api server before returning the final response.

Let's keep this issue rolling to brainstorm more ideas.

[logan-markewich]

I could imagine something like an output function or class thats defined, and the api server imports

output:
  service_name: EchoWorkflow
  # point to some function
  output_fn: formatters:parse_output
  # point to some pydantic class
  output_cls: formatters:MyOutputClass

Where I have some folder formatters/ that exports a function or class with those names, and runs them for that service