[shaohuzhang1]

fix: [Agent] A simple agent—configured with a "chat history" setting of 2 turns—fails to access prior context; the large language model responds as if the conversation is just beginning ("This is the start of the conversation").

[shaohuzhang1]

Issues / potential problems

1. Unused local variable

   • dialogue_number = application.dialogue_number is added but never used.
   • Both new assignments still call application.dialogue_number directly:

     data["nodes"][5]["properties"]["node_data"]["dialogue_number"] = application.dialogue_number
     data["nodes"][10]["properties"]["node_data"]["dialogue_number"] = application.dialogue_number

   • Either remove the local variable, or use it consistently:

     node_data["dialogue_number"] = dialogue_number

2. Possible AttributeError for legacy / versioned objects

   • application.dialogue_number is accessed three times. If not all Application / ApplicationVersion records have this field, build_workflow can fail.
   • Consider a safe fallback and validation:

     dialogue_number = getattr(application, "dialogue_number", None)

   • If None is not valid for the workflow schema, define an explicit default or skip assignment.

3. Published-version snapshot consistency

   • The code comments say published versions use a snapshot. Confirm that dialogue_number is part of the ApplicationVersion snapshot. If it is not versioned, published workflows may use a changing/current value or fail depending on the model.
   • This matters especially because the same function handles both Application and ApplicationVersion.

4. Workflow schema compatibility

   • Ensure dialogue_number is a supported property for the node_data of nodes 5 and 10.
   • If unsupported, workflow validation or frontend loading may fail, or the field may be silently ignored.
   • Validate the value type, e.g. non-negative integer, and reject/convert invalid strings.

5. Duplication and hard-coded node indices

   • The same property is assigned to two hard-coded nodes. This is already repeated for other fields such as mcp_servers, application_ids, and tool_ids.
   • Consider a small helper or loop to reduce missed updates:

     for node_index in (5, 10):
         node_data = data["nodes"][node_index]["properties"]["node_data"]
         node_data["dialogue_number"] = dialogue_number
         node_data["mcp_servers"] = application.mcp_servers
         node_data["application_ids"] = application.application_ids
         node_data["tool_ids"] = application.tool_ids

   • Hard-coded data["nodes"][5] / [10] is fragile if node order changes. If the workflow format allows it, resolve nodes by ID/type instead of index.

Suggested cleanup

dialogue_number = getattr(application, "dialogue_number", None)

for node_index in (5, 10):
    node_data = data["nodes"][node_index]["properties"]["node_data"]
    node_data["dialogue_number"] = dialogue_number
    # optionally set the other common fields here too

Tests to add

• Application with valid dialogue_number
• ApplicationVersion with valid dialogue_number
• Missing / None dialogue_number
• Invalid type/value
• Workflow schema validation for nodes 5 and 10

Overall: the main immediate issue is the unused local variable and repeated direct attribute access. The main longer-term risk is whether dialogue_number is guaranteed, versioned, and schema-compatible for both application types.