Chat_Message_fromString _O

Chat_Message_fromString _O is the old sibling of Chat_Message _O, and it's the version where the naming makes sense: it builds a chat message from a string. It lives in O/deprecated/OpenAI/Advanced/ChatGPT, kept for backward compatibility with pre-refactor workflows. If you've seen the error where a wire won't connect to a message node and the port type looks weird - this is usually the culprit.

What it is

Inputs are role (dropdown: user, assistant, or system) and content, but here's the rub: content is typed as STR, not STRING. That's the pack's old string-wrapper type - a legacy {"string": "..."} dict instead of a plain string. The node unpacks it with content["string"] and wraps it into an OPENAI_CHAT_MESSAGES list, same as the current version does.

The practical consequence: this node can't accept a plain text wire or a Text _O output directly - it expects the old wrapper type, which only the pack's deprecated string nodes produce. That's exactly the kind of impedance mismatch that leaves a saved workflow refusing to connect, and why the current Chat_Message _O takes a normal STRING instead.

What to use instead

The modern chain is the same shape, minus the legacy types:

1. load_openAI _O - client.
2. Chat_Message _O - plain STRING content, role dropdown.
3. combine_chat_messages _O - merge messages.
4. Chat completion _O - get the reply.

If a workflow you loaded references Chat_Message_fromString _O and it errors or won't wire up, replace it with the current Chat_Message _O - the drop-in fix is one node swap, and the message list output type is compatible with the same combine and completion nodes.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/omar92/ComfyUI-QualityOfLifeSuit_Omar92.git

or ComfyUI Manager → search ComfyUI-QualityOfLifeSuit_Omar92, then restart.

The honest take

This is a compatibility shim for workflows written when the pack used string-wrapper types, and nothing more. Its existence is why old graphs still load; its STR typing is why you shouldn't build anything new on it. One node swap to Chat_Message _O and you're on the current interface with none of the legacy type friction. Every deprecated node in this pack follows the same story: kept so the past doesn't break, superseded by a clean equivalent, and not worth adopting fresh.