Temporal Python SDK and Best Practices for LLM Projects

Community Support
1

Hello everyone! :wave:

First off, thank you so much for the amazing product. I’ve spent the last three days watching your YouTube videos and reading the manuals on your website. The overall system concept is fantastic! :smile:

We’re considering moving one of our projects to Temporal and have a few questions. I hope you can help clarify them:

Language Choice: I’m a big fan of Go and Java, but this project revolves around LLMs and communication between them. Since most of the great codebase in this niche is written in Python, we’re leaning towards using the Temporal Python SDK.

Pydantic Warning: On your GitHub Python examples page, we found a great example using the popular LangChain library, which really encouraged us. However, when we ran it, we encountered the following warning:

python playground/temporal/langchain/worker.py
2024-08-26 12:32:58.672 | INFO     | __main__:<module>:32 | Starting worker
/Users/derevo/.pyenv/versions/agents/lib/python3.12/site-packages/temporalio/converter.py:562: UserWarning: If you're using pydantic model, refer to https://github.com/temporalio/samples-python/tree/main/pydantic_converter for better support
warnings.warn("after reading documentation from temporal why this is happened 'Compiled Pydantic Sometimes Using Wrong Types'")

We’re a bit confused by this warning. While it’s not a huge issue for us to switch our models from Pydantic to Dataclass, it would be quite cumbersome to do so for other libraries we use.(almost all of them use Pydantic😅)

Advice Needed: How serious we should consider this warning? Should we be concerned about future problems with the deterministic state of the workflow? Any advice on how to mitigate these issues would be greatly appreciated.

Suggestions for Improvement: I’m open to any advice on how we might address this issue at the system architecture level. We’re still new to Temporal but believe it could be a game-changer for us, and we’re eager to make our small team’s work life better!

Thank you in advance for your help! :raised_hands:

2

The warning is telling you to use the approach at this sample for Pydantic V1 (we haven’t written it yet for Pydantic V2). Basically it’s just saying use a custom converter.

EDIT: This seems to be a common enough ask we are now exploring an official extension, but in the meantime a custom converter is the best way.

1 Like
3

I’m a bit confused about the differences between workflow.wait_condition() and workflow.wait() in Temporal workflows. Could someone explain the key differences and what’s happening under the hood?

Here’s my situation: I have two workflows with different requirements:

  1. One workflow needs to pause for up to a month and wait for a signal.
  2. Another workflow only needs to wait for a callback for a few minutes.

For short waits, it seems like workflow.wait_condition() is a good choice, but I’m not sure how to handle long waits efficiently. In the example from the Temporal samples repository, they use workflow.wait_condition() along with an asyncio.Queue().

How does this approach work for long waits? What’s the best practice for handling workflows that need to wait for a signal for an extended period?

5

This seems unrelated to the original thread discussion concerning Pydantic.

There is no such thing as workflow.wait().

These work well with wait_condition, e.g. await workflow.wait_condition(lambda: self.signal_received).

Long waits work well with that API too.

1 Like