@cl.step decorator doesn't correctly show inputs for functions of more than one variable

[thiagotps]

Describe the bug The input shown in the frontend of a function with more than one variable is wrong.

To Reproduce

import chainlit as cl

@cl.step(type="tool", show_input=True)
async def my_custom_tool(msg: str, some_parameter: bool):
    # Fake tool
    await cl.sleep(1)
    return "MSG: " + msg

@cl.on_message  # this function will be called every time a user inputs a message in the UI
async def main(message: cl.Message):
    """
    This function is called every time a user inputs a message in the UI.
    It sends back an intermediate response from the tool, followed by the final answer.

    Args:
        message: The user's message.

    Returns:
        None.
    """

    # Call the tool
    tool_res = await my_custom_tool("Hello World", True)

    await cl.Message(content=tool_res).send()

Expected behavior I was expecting to see

{
"msg": "Hello World",
"some_parameter":  true
}

as the logged input.

Screenshots

Desktop (please complete the following information):

• OS: Arch Linux
• Browser Firefox
• Version 130.0.1

Additional context Chainlit 1.2.0

[dosubot[bot]]

The issue you're experiencing with the @cl.step decorator not correctly showing inputs for functions with more than one variable might be related to how the inputs are being serialized and displayed in the frontend. The @cl.step decorator uses the flatten_args_kwargs function to bind and process multiple input parameters, which should normally handle this scenario correctly ^[1].

However, if the inputs are not being displayed as expected, it could be due to a bug in the serialization or display logic. Since the expected behavior is to see both parameters correctly serialized and displayed, and you're seeing an empty object for "some_parameter", this might indicate an issue with how the inputs are being captured or rendered.

To address this, you might want to check if there are any updates or patches available for Chainlit that address this issue. Additionally, reviewing the implementation of the flatten_args_kwargs function and how the inputs are serialized for the frontend might provide further insights into the problem.

To continue talking to Dosu, mention @dosu.