Different persistence for chat:completion event in Pipe and Action? #31612

Your observation matches the v0.11.4 implementation, but it is not chat:completion being persisted directly by get_event_emitter.

The emitter's database-write branches cover status, message, replace, embeds, files, and source/citation events, but not chat:completion.

The Action path differs on the client:

1. chatCompletionEventHandler applies the event's output or content to the in-memory message.
2. When the Action request completes, chatActionHandler saves the entire updated history with updateChatById.

That final whole-chat save is why the Action mutation survives a refresh. Pipe completion uses a separate backend persistence lifecycle, which explains the apparent inconsistency.

I cannot determine from the code whether the asymmetry is intentional, but there does not appear to be a public transient-Action event flag. Supporting this use case would require either skipping the post-Action history save for explicitly transient output or filtering/reverting those transient fields before updateChatById runs. Without such a flag, chat:completion from an Action should currently be treated as persistent client state.