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

[PR #94] [MERGED] feat: support more start event input formats in server API #112

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

📋 Pull Request Information

Original PR: https://github.com/run-llama/workflows-py/pull/94
Author: @adrianlyjak
Created: 9/12/2025
Status: ✅ Merged
Merged: 9/12/2025
Merged by: @adrianlyjak

Base: main ← Head: adrian/flexible-input

📝 Commits (2)

  • 424ea20 feat: support more start event input formats, so client doesnt need knowledge of python path
  • d7715ab remove forgotten comments

📊 Changes

3 files changed (+116 additions, -17 deletions)

View changed files

📝 src/workflows/context/serializers.py (+27 -10)
📝 src/workflows/server/server.py (+22 -7)
📝 tests/server/test_server_endpoints.py (+67 -0)

📄 Description

the client start event format is a bit awkward to work with, and doesn't necessarily need to be this way.

{"start_event":"{\"__is_pydantic\":true,\"value\":{\"file_id\":\"ec6a93ce-1cc9-4610-b684-d706a6212ac0\"},\"qualified_name\":\"test_proj.process_file.FileEvent\"}"}
  1. we can support passing in an object directly, rather than a string,
  2. the workflow has knowledge of the start event, so we can just use that

This change adds support for plain objects in addition to the previous format:

{"start_event": {"file_id":"ec6a93ce-1cc9-4610-b684-d706a6212ac0"}}

It also supports objects with the __is_pydantic fields.

Additionally, this adds validation that the start event is a conformant start event. Otherwise you'd need to call the result before getting this error message. (I think there's some further bugs where if you start streaming a workflow after it has failed, it just hangs indefinitely)

🔄 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/94 **Author:** [@adrianlyjak](https://github.com/adrianlyjak) **Created:** 9/12/2025 **Status:** ✅ Merged **Merged:** 9/12/2025 **Merged by:** [@adrianlyjak](https://github.com/adrianlyjak) **Base:** `main` ← **Head:** `adrian/flexible-input` --- ### 📝 Commits (2) - [`424ea20`](https://github.com/run-llama/workflows-py/commit/424ea205cdff5ec1ffd804d2458ea15aec306d31) feat: support more start event input formats, so client doesnt need knowledge of python path - [`d7715ab`](https://github.com/run-llama/workflows-py/commit/d7715ab8bfd4ebc5310dbc55a369196d2ad2c8e4) remove forgotten comments ### 📊 Changes **3 files changed** (+116 additions, -17 deletions) <details> <summary>View changed files</summary> 📝 `src/workflows/context/serializers.py` (+27 -10) 📝 `src/workflows/server/server.py` (+22 -7) 📝 `tests/server/test_server_endpoints.py` (+67 -0) </details> ### 📄 Description the client start event format is a bit awkward to work with, and doesn't necessarily need to be this way. ```json {"start_event":"{\"__is_pydantic\":true,\"value\":{\"file_id\":\"ec6a93ce-1cc9-4610-b684-d706a6212ac0\"},\"qualified_name\":\"test_proj.process_file.FileEvent\"}"} ``` 1. we can support passing in an object directly, rather than a string, 2. the workflow has knowledge of the start event, so we can just use that This change adds support for plain objects in addition to the previous format: ```json {"start_event": {"file_id":"ec6a93ce-1cc9-4610-b684-d706a6212ac0"}} ``` It also supports objects with the __is_pydantic fields. Additionally, this adds validation that the start event is a conformant start event. Otherwise you'd need to call the result before getting this error message. (I think there's some further bugs where if you start streaming a workflow after it has failed, it just hangs indefinitely) --- <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:38 -05:00
yindo closed this issue 2026-02-16 02:16:38 -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#112
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?