So i might have a rather dumb question, but i just could not find the answer anywhere, so …

Given that i have a workflow.py that imports some activities and other modules, i would put those imports within imports_passed_through, so that they are not re-imported for every workflow run (if im sure that they don’t case unwanted side-effects). So far i do understand the concept of sandboxing.

In the imported acitivity.py or helpers.py i now also import other modules, that i don’t want to be reloaded within the sandbox. Should i use imports_passed_through here, too, now? Or is imports_passed_through in the workflow.py recursive?

Also. Are acitvities themself also executed within an own sandbox? So do we need to use imports_passed_through here too, when they are executed for example by an own worker.

Thank you.

1 post - 1 participant

Read full topic

What it is

Graph Compose sits in the API orchestration / workflow automation space, adjacent to AWS Step Functions, Airflow, Argo Workflows, n8n, and Zapier, but with a different execution model. Workflows are declarative DAGs defined in JSON (or built visually), not code. The expression language is JSONata, so dynamic data flow between nodes doesn’t require writing Python or TypeScript. Under the hood, every workflow compiles to Temporal workflows + activities, so you inherit durability, retries, and event history without having to learn the Temporal SDK.

Users submit graphs via REST API or the TypeScript SDK (@graph-compose/client). Nodes can be HTTP calls, AI agents, iterators, error boundaries, webhooks, polling, conditionals, and forEach batching. There’s also a visual drag-and-drop builder (React Flow) and an AI assistant that generates workflows from natural language. All three interfaces submit to the same REST API.

Four Temporal patterns that might be interesting

forEach as child workflows. Each item in a batch spawns its own child workflow with a deterministic ID. 1 failure in 10k doesn’t affect the rest. Parent workflow uses signals to track completion and can fan back in with an endForEach node for continuation.

ADK agents as Temporal child workflows (Python). AI agents run as Python child workflows. State persists across turns using signals (receive_message, confirm_action, end_conversation). If the worker crashes between LLM calls, Temporal replays the conversation state from event history. Full writeup coming in a follow-up thread.

Human-in-the-loop via signals. Confirmation nodes set a flag, expose the pending action via query, and block on condition() until the signal arrives. Used for approval gates before agents take expensive actions or before workflows proceed to costly operations.

Error boundaries as subgraph isolation. Try/catch semantics at the workflow level. Protected nodes link via PROTECTS edges in a multigraph. A failed protected node routes to the boundary’s recovery handler (an HTTP call) instead of failing the parent. They nest.

What’s open source

The execution kernel, core types, and runtime are open source (AGPL-3.0):

• @graph-compose/execution-kernel: graph building, scheduling, validation, state, expression resolution, plugin/handler contracts

• @graph-compose/core: schemas, shared types, JSONata utilities

• @graph-compose/runtime: HTTP-only DAG execution on your own Temporal

The kernel is extensible beyond HTTP via a generic handler contract. Adding gRPC, message queues, or custom protocols is a matter of implementing a handler. GitHub: graph compose · GitHub

BYOK Temporal (short version)

If you run Temporal Cloud, you can plug in your address, namespace, and API key, and your workflows execute on your cluster. Implementation is a shared worker pool pattern with per-org task queues. Full architecture writeup coming in a follow-up thread.

Would love feedback on the execution patterns, especially from folks who’ve built similar things. Follow-up threads on the BYOK worker architecture and the ADK agent pattern coming soon.

Docs: Graph Compose Docs: API Workflow Automation Platform | Graph Compose

1 post - 1 participant

Read full topic

If you’ve been using an older version, please be aware of important changes described in the repo’s UPGRADING.md file. For a summary of the changes, you can also check out this blog post.

BTW, the 1.0.0 release was a milestone, not the end of the road, and there have been two more releases of the Helm Charts since then.

3 posts - 3 participants

Read full topic

Regards,

Dawid

2 posts - 2 participants

Read full topic

It might be due to k8s’s grpc check not supporting tls, not 100% sure on that though, I was using helm chart of version v0.73, and that did not have readiness probe.

I have set requireClientAuth: true in tls config when doing helm install. so this is my whole tls section:
```
tls:
frontend:
client:
rootCaFiles:
- /etc/temporal/certs/ca.cert
serverName: temporal-frontend.temporal.svc.cluster.local
server:
certFile: /etc/temporal/certs/cluster.pem
clientCaFiles:
- /etc/temporal/certs/ca.cert
keyFile: /etc/temporal/certs/cluster.key
requireClientAuth: true
internode:
client:
rootCaFiles:
- /etc/temporal/certs/ca.cert
serverName: temporal-frontend.temporal.svc.cluster.local
server:
certFile: /etc/temporal/certs/cluster.pem
clientCaFiles:
- /etc/temporal/certs/ca.cert
keyFile: /etc/temporal/certs/cluster.key
requireClientAuth: true
```

2 posts - 2 participants

Read full topic

Today I’ve begun the course Versioning Workflows with TypeScript. In the section “Versioning Workflows with the Patching API” (https://temporal.talentlms.com/plus/my/training/171/units/2925) there is some text do not make sense. The text is the following:

If the Workflow is not currently replaying an existing history, then the patched function will always return true. […] However, while the Workflow is replaying an existing history, and the history includes a patched call with the same patchId in the current Workflow code, then the patched function returns true.

The use of the “However” word makes me think the following sentence will have a different conclusion than the previous.

However, I understand I am beginning and may be clear for me later. If I am wrong, I can delete this post if you tell me to do so.

Thank you in advance.

1 post - 1 participant

Read full topic

I am developing with the Temporal Python SDK and trying to make use of the workflow test support. For context, I am using WorkflowEnvironment.start_time_skipping() and when needing to patch other functions/methods, I use configured Worker with UnsandboxedWorkflowRunner(). I am also using mocked activities and registering them to the Workflow env (and Worker).

An Issue I am having is debugging workflow tests. Often times, I am met with infinite buffering as a result of a misconfigured Workflow. However, sometimes the root cause is something minor like a missing param, a missing activity, or a small typo.

Is there anyway to get more precise error traces and feedback when a test fails? I want to avoid this buffering behavior since it is nondescript and results in a simple debug turning into hours of wasted time.

3 posts - 1 participant

Read full topic

1.29.0

using the official Helm chart

0.71.0

on GKE with GCS archival. I’ve configured archival in my Helm values under

server.config.archival

but the rendered

config_template.yaml

inside the pod always shows:

archival:
status: “disabled”

regardless of what I set in values.

My Helm values (

server.config.archival

section):

server:
config:
archival:
history:
state: “enabled”
enableRead: true
provider:
gstorage:
default:
credentialsPath: “”
visibility:
state: “enabled”
enableRead: true
provider:
gstorage:
default:
credentialsPath: “”
namespaceDefaults:
archival:
history:
state: “enabled”
URI: “gs://my-history-bucket”
visibility:
state: “enabled”
URI: “gs://my-visibility-bucket”

What I’ve tried:

• Setting

  server.archival
  

  (outside

  config
  

  ) — same result

• Enabling via

  temporal operator namespace update
  

  CLI — succeeds but namespace still shows

  HistoryArchivalState: Disabled
  

• Verified GCS buckets exist and Helm chart redeployed

Questions:

1. What is the correct Helm values path to enable archival in chart

   0.71.0
   

   ?

2. Does the chart support GCS archival config injection or does it require a manual

   ConfigMap
   

   patch?

3. Is

   server.config.archival
   

   the correct key or is there a different path?

Environment:

• Temporal server:

  1.29.0
  

• Helm chart:

  0.71.0
  

• Persistence: PostgreSQL

• Archival provider: GCS (

  gstorage
  

  )

• Platform: GKE with Workload Identity

3 posts - 1 participant

Read full topic

Is there a list available that shows the compatibility of Temporal Server and SDK versions?

Thanks

2 posts - 2 participants

Read full topic

we have example to open the environment via code spaces but for the JAVA tutorial that option is not coming.

Any help on this is much appreciated.

2 posts - 2 participants

Read full topic

invalid ID token: token invalid or expired

2026/04/10 20:13:16 [JWT Validation] Token verification failed: oidc: token is expired (Token Expiry: 2026-04-10 19:15:45 +0000 UTC)
2026/04/10 20:13:16 token_refresh_attempt ip=10.185.192.85
2026/04/10 20:13:16 token_refresh_failed reason=missing_refresh_token ip=10.185.192.85 duration_ms=0
2026/04/10 20:13:21 [Auth] Validating ID token from Authorization-Extras header
2026/04/10 20:13:21 [JWT Validation] Token verification failed: oidc: token is expired (Token Expiry: 2026-04-10 19:15:45 +0000 UTC)
2026/04/10 20:13:21 token_refresh_attempt ip=10.185.192.85
2026/04/10 20:13:21 token_refresh_failed reason=missing_refresh_token ip=10.185.192.85 duration_ms=0
2026/04/10 20:13:40 [Auth] Validating ID token from Authorization-Extras header
2026/04/10 20:13:40 [JWT Validation] Token verified successfully
2026/04/10 20:13:42 token_refresh_attempt ip=10.136.41.43
2026/04/10 20:13:42 token_refresh_failed reason=missing_refresh_token ip=10.136.41.43 duration_ms=0
2026/04/10 20:13:44 [Auth] Validating ID token from Authorization-Extras header
2026/04/10 20:13:44 [JWT Validation] Token verification failed: oidc: token is expired (Token Expiry: 2026-04-10 18:26:43 +0000 UTC)
2026/04/10 20:13:44 token_refresh_attempt ip=10.136.41.45
2026/04/10 20:13:44 token_refresh_failed reason=missing_refresh_token ip=10.136.41.45 duration_ms=0
sudo-sh[root@ip-10-122-150-170]# timed out waiting for input: auto-logout
Working directory prior to timeout: /home/e5us3s
sudo-sh[ssm-user@ip-10-122-150-170]$

environment:
  TEMPORAL_ADDRESS: temporal:7233
  TEMPORAL_UI_PORT: "8080"
  maxSessionDuration: "8h"
  TEMPORAL_AUTH_ENABLED: "true"
  TEMPORAL_AUTH_TYPE: "oidc"
  TEMPORAL_AUTH_PROVIDER_URL: "https://fmsso-devl.fanniemae.com"
  TEMPORAL_AUTH_ISSUER_URL: "https://fmsso-devl.fanniemae.com"
  TEMPORAL_AUTH_CLIENT_ID: "sso-p2x-IDS-d2-oidc-cots-Temporal"
  TEMPORAL_AUTH_CLIENT_SECRET: "****"
  TEMPORAL_AUTH_CALLBACK_URL: "https://temporal-idp-ec2.temporal.devl-utss.aws.fanniemae.com/auth/sso/callback"
  TEMPORAL_AUTH_SCOPES: "openid,email,profile"
  TEMPORAL_AUTH_SESSION_TTL: "1h"
  TEMPORAL_AUTH_SESSION_IDLE_TTL: "1h"
  TEMPORAL_AUTH_OIDC_TOKEN_REFRESH_ENABLED: "true"

3 posts - 2 participants

Read full topic

2 posts - 2 participants

Read full topic

We kept hitting the same problems. AI development has a lot of things to figure out that are unique to it - how do you iterate on a codebase packed with prompts? How do you orchestrate API calls that fail in unpredictable ways? How do you track what things actually cost? How do you test code that’s non-deterministic? On top of that, every piece of the tooling ecosystem is a different SaaS product that doesn’t talk to each other.

We focused on solving three things:

1. Make it easy for coding agents to work with your AI codebase. Filesystem-first - everything your agent needs is files it can read, organized in self-contained folders. TypeScript because it’s compiled and Zod gives agents validation and documentation together. We picked Claude Code and built a deep integration but the architecture works with any agent.

2. Self-contained. One package instead of a dozen SaaS subscriptions - prompts, evals, tracing, cost tracking, credentials. Your data stays on your infrastructure. Temporal is our orchestration layer and the one dependency we’re proud of - it’s scaled beautifully to millions of runs for us.

3. Fast learning curve. We have engineers at different levels and a lot of AI dev patterns are still being figured out. We baked in conventions so people don’t have to figure things out on their own for every project. The more advanced things - including Temporal’s power features - are abstracted until you actually need them.

We’ve been building this way for over a year. Some of the agents we’ve deployed for clients: one that creates website templates for Lovable from screenshots and ideas, one that generates connector docs for Airbyte every time a new connector is published, one that researches CVEs and writes detailed reports.

We finally got it to the point where we could finish the extraction and wanted to share it.

I wanted to share here with the community and I hope it can be useful to others.

1 post - 1 participant

Read full topic

My use case is like this:

• Microservice A is called first

• the response from Microservice A is used to build the request for Microservice B and stored in context.

• the response from Microservice B is used for Microservice C and stored in context

• and so on

So this is a strictly sequential flow where each next step depends on the previous step’s response.

A few important constraints:

• there are no compensating API calls

• after every microservice call, I need to persist the context pojo into a database table. Context pojo contains request and response

• I do not update existing rows

• each step creates a new row

• each new row contains the accumulated history from the previous step plus the current step’s request/response

• for example, when Microservice B completes, a new record is inserted that contains:

  • Microservice A request/response

  • Microservice B request/response

• then when Microservice C completes, another new record is inserted with:

  • Microservice A request/response

  • Microservice B request/response

  • Microservice C request/response

I’m trying to understand the best design for this in Temporal.

My main questions are:

1. What is the recommended way to model the evolving shared data between activities when each next service depends on the previous response?

2. Should this accumulated request/response history live in workflow state, activity input/output, or be rebuilt from external persistence?

3. Is it a good pattern to persist a new database row after every consecutive microservice call from within activities?

4. Are there any determinism or replay concerns if the workflow keeps growing an in-memory context object that contains all prior request/response data?

5. For a use case like this, is a single workflow with multiple sequential activities the right design, or is there a better Temporal pattern?

6. Are there any anti-patterns to avoid when combining sequential orchestration with insert-only audit/history records?

I’m mainly looking for design guidance.

4 posts - 2 participants

Read full topic

My test setup:

• The activity takes 1-2s to run

• At the start of activity, a timestamp is recorded to calculate activities per second later

Am I missing something or is there anything that I could do to strictly enforce the activities per second limit?

3 posts - 2 participants

Read full topic

I have a workflow that runs multiple sequential Local Activities, each taking ~2 seconds. I understand that Workflow Task Heartbeating kicks in automatically when a Local Activity takes longer than 80% of the Workflow Task Timeout (i.e., >8s with the default 10s WFT timeout).

My question is about the exact trigger point for Workflow Task Heartbeating when running several short Local Activities in sequence:

• Does the 80% threshold apply to the total elapsed time of the Workflow Task (i.e., across all Local Activities combined), or only to a single Local Activity’s execution time?

• Specifically: if I’m between two Local Activities (one just finished, the next hasn’t started yet) and the total elapsed time has already exceeded 80% of the WFT timeout — will a Workflow Task Heartbeat be triggered at that point?

Context: I have 5 Local Activities × ~2s each = ~10s total, which exceeds the 8s threshold. I want to understand whether the heartbeat fires mid-sequence or only while a Local Activity is actively running.

Thanks!

2 posts - 2 participants

Read full topic

You’ll learn:

• Nexus Endpoints, Services, and Operations
• Swapping an Activity call for a durable cross-namespace Nexus call
• Inspecting Nexus operations in the Web UI Event History

It’s hands-on: you start with a monolithic banking payment system, split it into two independently deployable services (Payments + Compliance), and prove durability by killing a Worker mid-transaction. Java SDK.

Let us know what you think or what Nexus patterns you’d like to see covered next!

1 post - 1 participant

Read full topic

Current setup

• Temporal is running in the blue cluster

• Applications are being migrated to the green cluster, currently pointing to Temporal in blue

Goal
During final cutover, we want to:

• Avoid downtime

• Continue starting new workflows

• Preserve all in-flight workflows without disruption

Question
Is it possible to run Temporal in both clusters (blue and green) simultaneously for a short duration (active-active) to enable gradual traffic shifting?

Understanding so far

• Multi-cluster replication follows an active-passive model

• Active-active for the same namespace is not supported

• Sharing a database across clusters may lead to shard ownership and consistency issues

Clarifications

1. Is there any supported approach to achieve zero-downtime migration in this scenario?

2. Is running two clusters temporarily against the same database ever safe or recommended?

Thanks!

1 post - 1 participant

Read full topic

We are adding more cpu, however, we cant find any guidelines on how determine these(cpu, memory..) parameters.

Are there guidelines on what alerts/thresholds to set for health monitoring?

Currently we have alerts set to 80% of cpu utilization on the history service.

We appreciate any guidelines/directions on the topic.

Thanks!

2 posts - 2 participants

Read full topic

We are running a self-hosted Temporal instance behind SSO authentication, which requires every request to include a valid JWT token. We have successfully completed the integration, and it is working as expected in general.

We are using the Temporal .NET SDK and attempting to connect a hosted Temporal worker to the Temporal service. Since authentication requires a valid JWT token, we explored multiple approaches to inject or refresh the token for outgoing requests. Below is a summary of what we tried and observed:

1. We attempted to override ClientOutboundInterceptor and WorkflowOutboundInterceptor. However, these interceptors do not expose the TemporalClient headers, so there is no way to attach a bearer token using this approach.

2. We explored intercepting gRPC requests directly. Unfortunately, the .NET SDK does not provide a way to register gRPC interceptors when configuring either the TemporalClient or the TemporalHostedWorker.

3. We then came across documentation suggesting that the token can be set during client registration. This approach works initially, but it is not a robust solution because JWT bearer tokens are short-lived. Since the TemporalClient is long-lived, it continues using the same token for all subsequent calls, which eventually leads to authentication failures in long-running workers.

4. To address this, we implemented a hosted background service that periodically refreshes the JWT token and updates the TemporalClient’s RpcMetadata. This solution works, but it introduces additional complexity. It requires running and monitoring an extra background service, and if token acquisition fails, the worker starts failing due to authentication errors. Although we have implemented retries, all of this logic is custom and increases operational risk.

Given the above, our question is: does the Temporal .NET SDK provide any built-in mechanism to dynamically refresh or supply JWT tokens for the Temporal client, so that we do not need to maintain an additional background service solely for token refresh?

Please let us know if any additional details are required from me.

2 posts - 1 participant

Read full topic

we are migrating Camunda 7.12 to Temporal for Cloud Security reasons and support reasons. Can you help me to migrate Camunda Inflight and closed orders to Temporal. How this can be done in simple way.

Regards,

Thanuja.

3 posts - 2 participants

Read full topic

Workflow characteristics

These are not simple fire-and-forget tasks. Each workflow has:

• Multiple steps
• Readiness checks that block — the workflow must wait if a dependency isn’t ready, then resume when it is
• Some workflows trigger further downstream processing

This multi-step + durable wait behavior is why we’re evaluating Temporal over simpler task queues.

Our planned setup

• Persistence backend: PostgreSQL (not Cassandra)

Our concerns

1. Postgres throughput ceiling — benchmarks suggest ~50–200 workflow starts/sec on Postgres. At that rate, 60k workflows would take 5–20 minutes just to start, leaving little time for
   processing before the next 15-min cycle.
2. Thundering herd on the DB — 60k simultaneous starts means massive burst writes to history_node and executions tables.
3. Jitter may not help enough — with a 15-min cycle, adding 5+ min of jitter defeats the purpose of the schedule.

Questions

1. Has anyone run Temporal + Postgres at this scale (60k bursty scheduled workflows)? What was your experience?
2. Is there a recommended pattern for bursty cron-style workloads beyond jitter?
3. Is Postgres the wrong choice here — should we commit to Cassandra from the start?
4. Any guidance on history shard count and Postgres sizing for this scale?

Any real-world experience or architectural guidance appreciated.

1 post - 1 participant

Read full topic

1 post - 1 participant

Read full topic

However I’m not sure that’s the best approach for my use case.

I’m handling a series of Scheduled jobs, that run every 10 minutes, and retrieve data from System A, and dump into Database B.

Although idempotent, I’m trying to optimize this process by only grabbing new data that was created after the last time we successfully downloaded data. When looking at the last runs of a Scheduler, I only get 10 and seemingly no guarantee that any of those 10 were actually Completed successfully. And when looking at the Workflow handler, I can see if the last run was successful, but if it wasn’t, I can’t seem to find a good way to retrieve the last successful run.

Ideally I’d be able from within my Download Activity Execution to query for the last time a given Workflow was scheduled and ran successfully.

Am I missing something obvious here? Any help would be greatly appreciated.

1 post - 1 participant

Read full topic

One thing that keeps causing some issues is signals somehow entering the workflow object before its workflow method was called. Seems to only happen in replay/continueAsNew scenarios.

In another thread I’ve seen a similar question that got a different answer from my observed behavior. Namely that the workflow method is always executed first up until at least its first await and that after a continueAsNew:

The workflow state will be rolled back to the state before the signal was received and signal will be delivered.

Therefore, I’d like to get some confirmation on if this is working as intended or not.

My workflow method sets a state variable, early on before calling any awaits.

My signal handler reads from this state object but, it is not set yet resulting in a NullPointerException.

For me this is quite hard to work with but moreover seems like a clear difference in how continued vs new workflows behave.

So to be clear, is the WorkflowMethod meant to execute first afer any new workflow object creation and if not how is this typically meant to be handled?

5 posts - 3 participants

Read full topic

1 post - 1 participant

Read full topic

Below is an image of a Docker container that has not received anything to process for hours, but the memory is stuck at 732 MB and does not go down even with nothing to process. If I create new workflows, it only keeps growing more and more until the container runs out of memory. These tests were done in both Docker and Kubernetes, and the result was the same.

At the beginning the Python version was 3.10 now we are using 3.12
Temporal version: 1.23.0

2 posts - 1 participant

Read full topic

After an activity completes, the next activity in the workflow sequence should be scheduled promptly — with only minimal overhead (milliseconds) between ActivityTaskCompleted and the next ActivityTaskScheduled event in the workflow history. In a healthy Temporal setup, the Workflow Task that drives the next execute_activity call should be picked up and executed quickly, even under moderate concurrency with child workflows.

Actual Behavior

A blank/invisible gap of 10–20 seconds appears between consecutive activities in the same ChildWorkflow. Specifically:

• An activity (e.g. predict_feedback_reference) completes successfully

• No next activity is scheduled for 10–20 seconds

• Only after that gap does the next activity (e.g. predict_transaction_merchant) appear as ActivityTaskScheduled

This gap occurs before the next activity is scheduled — meaning the delay is in Workflow Task pickup/execution, not in the activity queue or the activity execution itself. This is observed in both local Docker and Temporal Cloud environments, across a workload of ~50–150 concurrent child workflow executions.

Steps to Reproduce the Problem

1. Run a Temporal server locally via Docker with constrained resources (cpus: 0.5, mem_limit: 1024m)

2. Start a single worker process with MAX_CONCURRENT_WORKFLOW_TASKS=100 and MAX_CONCURRENT_ACTIVITIES=100 on the same machine

3. Trigger a parent workflow that fans out to 50–150 child workflows, each executing 4 sequential activities via await workflow.execute_activity(...)

4. Open the Temporal UI and inspect the event history of any child workflow

5. Observe the timestamp gap between ActivityTaskCompleted and the subsequent ActivityTaskScheduled — expect ~10–20 second blank gaps

Specifications

1 post - 1 participant

Read full topic

wanted to see if there is different approach than this and if this IS the best way of going about it.

Signal can be sent to a workflow definition at any time to approve/reject the process…it should only be available when the process has finished doing background work aka fetching data…etc

how to ignore/dismiss an early Signal? is there a better alternative than this?

mitigating STATE

@SignalMethod
public void approve() {
    if (state != State.WAITING_FOR_APPROVAL) {
        Workflow.getLogger(getClass()).info("Approval received too early. Ignoring.");
        return;
    }

    approved = true;
}

ty

1 post - 1 participant

Read full topic

I’m working on migrating some long-running business processes to Temporal and would love to hear your experiences and best practices.

Specifically, I’m dealing with workflows that:

- Run for days or weeks (customer onboarding, approval chains)

- Need to handle human tasks and wait for external events

- Require visibility into current state for business stakeholders

How do you typically model these? Do you:

- Use signals for external events or prefer polling activities?

- Create child workflows for sub-processes or keep everything in one workflow?

- Handle versioning when business rules change mid-flight?

Any patterns or lessons learned would be greatly appreciated!

Thanks in advance.

1 post - 1 participant

Read full topic