Bug_195_MUST_FIX: CHAT-BOUNDARY-012 — description=None crashes _call_start_workflow with unhandled TypeError

[steadhac]

Component: finbot/agents/chat.py → VendorChatAssistant._call_start_workflow (line 229)

Root cause:

# chat.py line 229
summary=f"Chat workflow started: {description[:100]}",

description is a required string parameter with no None guard. When the LLM omits
the field or sends null, description=None reaches line 229 where None[:100] raises
TypeError: 'NoneType' object is not subscriptable. This exception is unhandled —
it propagates out of the method as a 500-class error.

Steps to reproduce:

1. Create a VendorChatAssistant with a mock background_tasks.
2. Call _call_start_workflow(None, vendor_id=1).

Expected: {"error": "description is required"} — clean error JSON
Actual: TypeError: 'NoneType' object is not subscriptable — unhandled exception

How to execute:

pytest tests/unit/agents/test_chat_assistant.py::TestBoundaryAndTypeValues::test_chat_boundary_012_description_none_crashes_before_dispatch -v

Proposed fix:

if not description and description is not None:
    pass  # empty string allowed — validated separately
if description is None:
    return json.dumps({"error": "description is required"})

Or add a guard at the top of the method alongside the background_tasks check:

if description is None or vendor_id is None:
    return json.dumps({"error": "description and vendor_id are required"})

Impact: Any LLM tool call that omits description causes an unhandled exception.
The background task is never enqueued. The caller receives no structured error —
just an uncaught TypeError propagating up the call stack, which at the FastAPI layer
becomes a 500 response. The crash happens after background_tasks.add_task has already
been called (line 208), so the workflow ID may have been allocated but never properly
tracked.

Note: This and TICKET 9 share the same fix location. They should be resolved together.

Acceptance criteria:

• test_chat_boundary_012_description_none_crashes_before_dispatch updated to assert error JSON (once fix is applied)
• _call_start_workflow returns {"error": ...} when description is None
• No unhandled TypeError propagates to the caller
• All other _call_start_workflow tests continue to pass

[Jean-Regis-M]

@nitinawari @steadhac Root cause appears to be missing null-check on description before invoking _call_start_workflow. I’ll add input validation and ensure graceful error handling instead of propagating TypeError.