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.

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

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.

        services.AddHostedTemporalWorker(
            clientTargetHost: "host-name:443",
            clientNamespace: "default",
            taskQueue: "task-queue")
            .ConfigureOptions(options =>
            {
                options.ClientOptions!.Tls = new()
                {
                    Disabled = false,
                };
            })
            .AddWorkflow<WorkflowHelloWorld>()
            .AddScopedActivities<HelloWorldActivity>();

solution works with Temporalio.Extensions.Hosting 1.13.0.

Done.

I’d check the frontend readiness probe first and move it off the mTLS gRPC path, either use an HTTP health endpoint or a probe that runs with the same certs the frontend expects. If you keep the stock gRPC probe on 7233, it will keep failing even when Temporal itself is healthy.

Currently available via CLI and the SDK.

Antonio

Regards,

Dawid

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
```

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.

There is no formal compatibility matrix between Temporal Server and SDK versions, in theory you should be able to use any SDK version.

We release new versions of the Temporal SDKs and Temporal Server software independently of one another. That said, All SDK versions support all server versions.

A couple of things that helped me get better visibility into what’s going wrong:

• Enable more verbose logging: Setting the logging level to DEBUG for Temporal internals can sometimes surface where the workflow is getting stuck.

• Validate activity registration explicitly: Before running tests, I added small assertions/logs to confirm all expected activities are registered. Missing activities are a common silent failure point.

• Wrap workflow execution with timeouts: Even in test environments, adding a timeout around workflow execution can at least fail fast instead of buffering forever.

• Use smaller isolated tests: When debugging, I try to run the workflow with minimal inputs and mocked dependencies to narrow down where the issue starts.

• Check sandbox vs unsandboxed differences: I’ve noticed subtle behavior differences when using UnsandboxedWorkflowRunner(), especially with patched functions—worth double-checking those patches are actually applied.

Also, for small mistakes like typos, missing params, or naming mismatches, I’ve found tools like a name generator helpful for quickly validating consistent naming patterns across workflows, activities, and mocks—it reduces those tiny errors that can cause big debugging headaches.

Would definitely love if Temporal adds better error surfacing here, but for now these workarounds made things a bit more manageable.

Server.config.archival values not applied to config_template.yaml when using Temporal Helm chart 0.71.0 Community Support

I’m deploying Temporal 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…

maxim:

activity

The app was releasing memory normally in the code. The question was that we are running the workflow in sandbox (default in python sdk), so after each workflow execution, the memory increases indefinitely. After passthrought modules in workflow, the memory usage was normalized.

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.

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

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

Thanks

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.

I’m already using a queueing based approach but still it helps the use-case a lot to be able to always validate input using the @UpdateValidatorMethod with the garantee of certain state being set.

With TEMPORAL_AUTH_OIDC_TOKEN_REFRESH_ENABLED=true, Temporal expects a refresh token once the ID token expires. Right now you’re only requesting openid,email,profile, so I’d check whether your IdP/client is actually issuing refresh tokens for this app. In a lot of setups that means adding offline_access and making sure the client is using the authorization code flow, not a flow that only returns an ID token.

I’d verify those two things first: the token response after login actually contains a refresh token, and the IdP’s ID token lifetime for this client isn’t only a few minutes.

If no refresh token is returned, the UI session will keep dying as soon as the ID token ages out, no matter what you set for the Temporal session TTL.

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"

You can use @WorkflowInit to initialize the workflow variables,

add the received signals to a queue.

I also like this approach, where you add messages to the queue and, in the main workflow method, have the logic to extract and process them one by one.

time=2026-04-09T21:45:23.567 level=ERROR msg=“Operation failed with internal error.” error=“UpdateTaskQueue failed. Failed to start transaction. Error: context canceled” error-type=serviceerror.Unavailable operation=UpdateTaskQueue

time=2026-04-09T21:45:23.567 level=ERROR msg=“Persistent store operation failure” component=matching-engine wf-task-queue-name=/_sys/default-worker-tq/3 wf-task-queue-type=Workflow wf-namespace=temporal-system worker-version=_unversioned_ backlog=classic store-operation=update-task-queue error=“UpdateTaskQueue failed. Failed to start transaction. Error: context canceled”

Important detail: I’m running temporal without any kind of persistence, on my machine:

temporal server start-dev

sum by (operation) (rate(service_requests{service_name=“history”}[$rate]))

(same for service errors - service_errors)
and lets go from there

For memory:

avg(cache_usage{cache_type=“mutablestate”})
avg(cache_pinned_usage{cache_type=“mutablestate”})

also cache_requests:

sum(rate(cache_requests{cache_type=“events”,operation=“EventsCachePutEvent”}[1m]))
sum(rate(cache_requests{cache_type=“events”,operation=“EventsCacheGetFromStore”}[1m]))

see if there is correlation of these to your resource utilization

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?

Sdk can check if it needs to extend workflow task while local activity is dispatched (so dispatched + running, until it completes) , so its per single local activity execution within that workflow task

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?

not in-between, but when worker starts dispatching and executing next local activity, it will detect that it reached 80% workflow task timeout and at that point send workflow task heartbeat

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.

while its dispatched and running, so if your local activity 4 completes at lets say 8.1s into workflow task, worker will detect that while this 4th local activity is running and issue workflow task heartbeat
if 4th activity completes lets say right at 8s or 7.9s, worker will dispatch local activity 5, and then learn that it needs to send workflow task heartbeat
note that local activity 5 is not re-executed in new workflow task requested by sdk, it will continue running

hope this helps

In Python SDK a common issue is making synchronous API calls inside the async activity implementations blocking the whole asyncio loop.

i don’t think i have any synchronous blocking task inside the activity, i am only using httpx for http calls and beanie ( which also uses Asyncpymongo ) for db calls, so that shouldn’t be the issue, there are some html parsing tasks happening on main thread only, but i don’t think that should block the main thread more than timeout ( which is approx 5 min ) , will move them to asyncio.to_thread as precaution

Flow control is the feature. The solution is to have enough processing slots and release them in the timely manner.

i do have max_activities_per_second for each activity ( which is mostly in range of 5-20 due to external rate limits so i can’t increase them even with more workers ) which do any external call, but yes the activities can be scheduled a lot more frequently ( maybe 200-500 at once ) in a single workflow, and there are multiple such parellel workflows, i assumed the the max_activities_per_second limit will keep the activity execution count in check but will still execute given enough time, but in my case the execution just stopped, there are no new logs suddenly in the worker without any error or warning neither in the worker logs nor in the UI

so this imbalance in inflow and outflow can cause this issues ? or any other way to find out what exactly is the issue for sudden halts in execution

also the server starts picking tasks again when i restart it

also i have noticed a pattern that this happens mostly when there is some
[TMPRL1101] Potential deadlock detected: workflow didn’t yield within 2 second(s).

but i have don’t have any sync code in the workflow and while iterating on large data loops i use workflow.sleep(0) but i use pydantic-data-converter

Also, instead of create 1 main workflow and millions of child workflows, would it be ok if we create millions of workflow ?

Imho yes, Temporal scales on number of executions

The way you can calculate max burst is using ceiling function for example here

Default number of task queue partitions for a task queue is 4, so

burst-per-partition = ceiling(TaskQueueActivitiesPerSecond/numOfTaskQueuePartitions)
so for your use case (im assuming you didnt change default num of task queue partitions)
burst-per-partition = ceiling(5/4) = 2

This means that at time T server can dispatch up to 2 * numOfTaskQueuePartitions = 8
activity tasks, and at time T+1 it would not dispatch any so that over time it will maintain 5/s.

If you need very strict dispatch limit (so have to stay at and under 5/s)
and the throughput of your activities is not extremely high you could lower number of task queue partitions to 1 for this activity task queue via dynamic config, see sample here
this will give you burst of 5 with single partition, so your at your limit.

Alternatively set TaskQueueActivitiesPerSecond to 4 which then would give you burst

burst-per-partition = ceiling(4/4) = 1
so thats burst of 4 across default num of partitions which will stay under you 5 limit

Also, instead of create 1 main workflow and millions of child workflows, would it be ok if we create millions of workflow ?

In Python SDK a common issue is making synchronous API calls inside the async activity implementations blocking the whole asyncio loop.

i am using cloud temporal with temporal python sdk: 1.21.1

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.

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.

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?

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!

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!