run-llama/workflows-py
1
0
Fork 0
mirror of https://github.com/run-llama/workflows-py.git synced 2026-07-20 19:57:02 -04:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

[PR #152] [MERGED] Normalize server/client event schema #168

New Issue
Closed
opened 2026-02-16 02:16:48 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 02:16:48 -05:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/run-llama/workflows-py/pull/152
Author: @adrianlyjak
Created: 10/18/2025
Status: ✅ Merged
Merged: 10/20/2025
Merged by: @adrianlyjak

Base: main ← Head: adrian/events

📝 Commits (2)

📊 Changes

10 files changed (+495 additions, -216 deletions)

View changed files

📝 examples/client/base/workflow_client.py (+1 -1)
📝 examples/client/human_in_the_loop/workflow_client_hitl.py (+2 -2)
📝 src/workflows/client/client.py (+33 -29)
📝 src/workflows/context/serializers.py (+3 -6)
➕ src/workflows/protocol/serializable_events.py (+188 -0)
➖ src/workflows/server/serialization.py (+0 -59)
📝 src/workflows/server/server.py (+66 -47)
📝 tests/client/test_client.py (+6 -4)
➕ tests/protocol/test_serializable_events.py (+196 -0)
➖ tests/server/test_serialization_envelope.py (+0 -68)

📄 Description

Adds a more normalized server/client event schema. Bails on using the JsonSerializer, it's recursive thing isn't really useful.

{
   "type": "Foo",
   "value": { "bar": 1 },
    // optionally included when reading. Maintains support for parsing event from this field
    "qualified_name": "package.Foo",
    // always included when reading, not used when sending events
    "types": ["StartEvent"]
}

Maintains support for bare (not wrapped) events when posting a run to a workflow

Additionally, maintains support for all of the many various formats that we've accumulated

  • specifying events as strings (both bare events for start_event, and wrapped with type data)
  • reading based on the qualified_name rather than the type
  • reading from data rather than value (this one was recently added. I preferred value since its been the historical convention via JsonSerializer)

Note, breaking change!

  • Updated the stream events api in the client to return a pydantic model rather than a bare dict. This has only been released for a week, so seems fine to throw it in real quick

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/run-llama/workflows-py/pull/152 **Author:** [@adrianlyjak](https://github.com/adrianlyjak) **Created:** 10/18/2025 **Status:** ✅ Merged **Merged:** 10/20/2025 **Merged by:** [@adrianlyjak](https://github.com/adrianlyjak) **Base:** `main` ← **Head:** `adrian/events` --- ### 📝 Commits (2) - [`4c6bed4`](https://github.com/run-llama/workflows-py/commit/4c6bed46f9aaa307bee656ae952fa324b62e53c8) wip - [`feb2cab`](https://github.com/run-llama/workflows-py/commit/feb2cab6779f43b01fe99d88667ab321d06e0029) finish up ### 📊 Changes **10 files changed** (+495 additions, -216 deletions) <details> <summary>View changed files</summary> 📝 `examples/client/base/workflow_client.py` (+1 -1) 📝 `examples/client/human_in_the_loop/workflow_client_hitl.py` (+2 -2) 📝 `src/workflows/client/client.py` (+33 -29) 📝 `src/workflows/context/serializers.py` (+3 -6) ➕ `src/workflows/protocol/serializable_events.py` (+188 -0) ➖ `src/workflows/server/serialization.py` (+0 -59) 📝 `src/workflows/server/server.py` (+66 -47) 📝 `tests/client/test_client.py` (+6 -4) ➕ `tests/protocol/test_serializable_events.py` (+196 -0) ➖ `tests/server/test_serialization_envelope.py` (+0 -68) </details> ### 📄 Description Adds a more normalized server/client event schema. Bails on using the `JsonSerializer`, it's recursive thing isn't really useful. ```js { "type": "Foo", "value": { "bar": 1 }, // optionally included when reading. Maintains support for parsing event from this field "qualified_name": "package.Foo", // always included when reading, not used when sending events "types": ["StartEvent"] } ``` Maintains support for bare (not wrapped) events when posting a run to a workflow Additionally, maintains support for all of the many various formats that we've accumulated - specifying events as strings (both bare events for start_event, and wrapped with type data) - reading based on the `qualified_name` rather than the `type` - reading from `data` rather than `value` (this one was recently added. I preferred `value` since its been the historical convention via `JsonSerializer`) **Note, breaking change!** - Updated the stream events api in the client to return a pydantic model rather than a bare dict. This has only been released for a week, so seems fine to throw it in real quick --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-02-16 02:16:48 -05:00
yindo closed this issue 2026-02-16 02:16:48 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
enhancement
good first issue
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: run-llama/workflows-py#168
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?