Avoid printing some stack traces in the logs?

Community Support
1

Hello,

using the python-sdk, when an exception is raised from a workflow or an activity, the stracktrace is shown in the logs along side the exception message. It repeats itself until the workflow fails because of the retry policy.

For unexpected exception it makes sens, but for expected exception, the stack trace does not make sense et produce noise in the logs.

Is it possible to avoid the stack trace on some specific exception ?

Thank you

++ Jérôme

2

Thanks Jérôme! Is there a specific example of something you’d like to suppress?

3

Hello,

I have a specific exception defined like

class Retry(Exception):
  pass

in a workflow in which the Retry exception is raised. In the worker’s log I got the following message. As the Retry exception is know, I don’t need the stack trace and it pollutes the logs. And the error is logged twice (once " Failed activation on workflow" and one “Failing workflow task”).

it’s a lot of useless stuff that noises the logs and slows the time to analyse what’s happening.

Failed activation on workflow Sample with ID Sample-380788 and run ID 01983813-4b98-7ec8-a0cb-1d4f08925a72
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 412, in activate
    self._run_once(check_conditions=index == 1 or index == 2)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 2130, in _run_once
    raise self._current_activation_error
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 2148, in _run_top_level_workflow_function
    await coro
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 974, in run_workflow
    result = await self._inbound.execute_workflow(input)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 2529, in execute_workflow
    return await input.run_fn(*args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/pcs/robots/workflows/sample.py", line 70, in run
    raise Retry(f"error but retry with message '{params.task.arguments['retry']}'")
pcs.robots.lib.exceptions.Retry: error but retry with message 'RetryNormalException'
2025-07-23T16:17:25.462269Z  WARN temporal_sdk_core::worker::workflow: Failing workflow task run_id=01983813-4b98-7ec8-a0cb-1d4f08925a72 failure=Failure { failure: Some(Failure { message: "error but retry with message 'RetryNormalException'", source: "", stack_trace: "  File \"/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py\", line 412, in activate\n    self._run_once(check_conditions=index == 1 or index == 2)\n    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n  File \"/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py\", line 2130, in _run_once\n    raise self._current_activation_error\n\n  File \"/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py\", line 2148, in _run_top_level_workflow_function\n    await coro\n\n  File \"/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py\", line 974, in run_workflow\n    result = await self._inbound.execute_workflow(input)\n             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n  File \"/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py\", line 2529, in execute_workflow\n    return await input.run_fn(*args)\n           ^^^^^^^^^^^^^^^^^^^^^^^^^\n\n  File \"/app/pcs/robots/workflows/sample.py\", line 70, in run\n    raise Retry(f\"error but retry with message '{params.task.arguments['retry']}'\")\n", encoded_attributes: None, cause: None, failure_info: Some(ApplicationFailureInfo(ApplicationFailureInfo { r#type: "Retry", non_retryable: false, details: None, next_retry_delay: None, category: Unspecified })) }), force_cause: Unspecified }
2025-07-23 16:17:25,473 [worker masterbot] [@db_session] session.merge(Task#380788
2025-07-23 16:17:25,526 [worker masterbot] Failed activation on workflow Sample with ID Sample-380788 and run ID 01983813-4b98-7ec8-a0cb-1d4f08925a72
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 412, in activate
    self._run_once(check_conditions=index == 1 or index == 2)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 2130, in _run_once
    raise self._current_activation_error
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 2148, in _run_top_level_workflow_function
    await coro
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 974, in run_workflow
    result = await self._inbound.execute_workflow(input)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/temporalio/worker/_workflow_instance.py", line 2529, in execute_workflow
    return await input.run_fn(*args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/pcs/robots/workflows/sample.py", line 70, in run
    raise Retry(f"error but retry with message '{params.task.arguments['retry']}'")
pcs.robots.lib.exceptions.Retry: error but retry with message 'RetryNormalException
4

I managed to hack the logger to not print stack trace when it’s a Retry exception.

There’s still, the first time the Retry exception is raised from a workflow, the following message that is logged and it seems to be outside of any logging configuration.

2025-07-24T06:43:40.569308Z  WARN temporal_sdk_core::worker::workflow: Failing workflow task run_id=01983b2c-5f50-79a7-a86e-3d8884739b5a failure=Failure

I’m search from the source of this log

5

note: if I set the default logging level to ERROR, still this WARN message is displayed while all others are gone (as expected as they are set to INFO). But warn should be gone also with a level set to ERROR.

6

I’m search from the source of this log

This log is from the core sdk — are you familiar with that?

This sample shows how to change the level of specific logs. I’m not sure if it’ll help you in this specific use-case.

Lastly, you may also be able to use log forwarding. We don’t have a sample for it, but you can see it in test_runtime.py of this PR

7

Just for reference, you can set application error category to benign for ApplicationError you raise in activity code for your use case, for eample:
raise ApplicationError(
message="..",
// …
category=ApplicationErrorCategory.BENIGN,
)