fix(utils): stop wrapper_async submitting the sync success handler twice

[devin-ai-integration]

TLDR

Problem this solves:

• Async requests ran the sync success pipeline twice per call
• Two logging threads mutated the same logging object at once
• Legacy success_callback functions fired twice per request

How it solves it:

• The async logging task no longer re-submits the sync success handler
• The direct dispatch at request completion is the one remaining submission

User Flow

Before: an operator with a plain success_callback function configured sees it fire twice for every request

1. They add litellm_settings.success_callback: ["my_module.my_callback"] to the proxy config and start the proxy with --detailed_debug
2. They send POST http://localhost:4000/v1/chat/completions with {"model":"gpt-5.4-mini","messages":[{"role":"user","content":"Reply with the single word: pong"}],"max_tokens":16}
3. The response is 200 with a chatcmpl-... object and "content":"pong"
4. The proxy log shows two Logging Details LiteLLM-Success Call lines for that one request, and their callback receives the same request twice, from two different threads at the same time

After: the same request drives the callback exactly once

1. They add litellm_settings.success_callback: ["my_module.my_callback"] to the proxy config and start the proxy with --detailed_debug
2. They send POST http://localhost:4000/v1/chat/completions with {"model":"gpt-5.4-mini","messages":[{"role":"user","content":"Reply with the single word: pong"}],"max_tokens":16}
3. The response is 200 with a chatcmpl-... object and "content":"pong"
4. The proxy log shows one Logging Details LiteLLM-Success Call line for that request, and their callback receives it once

Relevant issues

Affected release

Linear ticket

Resolves LIT-6931

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.). All 88 checks green on d13e8dc, Bugbot reviewed d13e8dc and found no issues. Veria has not posted a check on this head, so it is recorded as not run rather than passed
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes). Greptile scored d13e8dc 5/5

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

This PR re-targets #41058 at main. That PR merged into litellm_internal_staging after the branch was retired, so its fix never reached main. The diff is byte-for-byte the same as the merged #41058 diff (git diff 1f8bae7eab^1 1f8bae7eab against git diff origin/main HEAD, ignoring index lines)

Root cause: wrapper_async ends every successful async call in _dispatch_success_logging, which submits logging_obj.success_handler to the logging thread pool directly and also schedules _client_async_logging_helper, and that helper submitted the very same success_handler a second time. Both executor threads then ran _success_handler_body against one logging object. The fix deletes the second submission from the helper; the helper now only enqueues async_success_handler. The diff is a 9 line removal in litellm/utils.py plus one regression test

Scope: this PR covers the non-streaming async path (acompletion, aresponses, aembedding, everything that goes through wrapper_async). Streaming completions finish their logging in CustomStreamWrapper through dispatch_success_handlers, a separate code path this PR does not touch. The sync wrapper submits success_handler once and is also unchanged

Shared setup (both arms, no database, so the observable is the debug log line the sync success_handler prints once per run):

# ~/lit6931/config.yaml
model_list:
  - model_name: gpt-5.4-mini
    litellm_params:
      model: openai/gpt-5.4-mini
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  success_callback: ["lit6931_callbacks.customer_success_callback"]

general_settings:
  master_key: sk-lit6931

# ~/lit6931/lit6931_callbacks.py
def customer_success_callback(kwargs, completion_response, start_time, end_time):
    pass

PYTHONPATH=<worktree>:~/lit6931 litellm --config ~/lit6931/config.yaml --detailed_debug --port 46931 > ~/lit6931/proxy_<arm>.log 2>&1
for i in 1 2 3; do
  curl -s http://127.0.0.1:46931/v1/chat/completions \
    -H "Authorization: Bearer sk-lit6931" \
    -H "Content-Type: application/json" \
    -d '{"model":"gpt-5.4-mini","messages":[{"role":"user","content":"Reply with the single word: pong"}],"max_tokens":16}'
  echo; sleep 2
done
grep -c "Logging Details LiteLLM-Success Call" ~/lit6931/proxy_<arm>.log
grep -c "Logging Details LiteLLM-Async Success Call" ~/lit6931/proxy_<arm>.log

Before (b94b8bc)

1. sha256sum litellm/utils.py on the served checkout gave 378c6a4c..., matching git show b94b8bca21:litellm/utils.py, and Initialized Success Callbacks - [<function customer_success_callback ...>] appears once in proxy_before.log
2. The three curls returned 200 with "content":"pong" (chatcmpl-EO74vT3nQIrLnXhwdh6Frj0D12pG9, chatcmpl-EO74yzgNwHeXYeOs1DFecXgCgoBjl, chatcmpl-EO750SrTsvIJzNg8ozSJq2lQFyIkM)
3. Counts from proxy_before.log:

$ grep -c "Logging Details LiteLLM-Success Call" proxy_before.log
6
$ grep -c "Logging Details LiteLLM-Async Success Call" proxy_before.log
3
$ grep -n "Logging Details LiteLLM-Success Call" proxy_before.log
968:19:56:29 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
996:19:56:29 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
1148:19:56:32 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
1165:19:56:32 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
1357:19:56:35 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
1392:19:56:35 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None

4. Two sync success-handler runs per request (one pair per request timestamp), so the configured sync callback fires twice per request on main

After (d13e8dc)

1. Proxy restarted from the PR worktree: sha256sum litellm/utils.py gave e9d9402c..., matching git show d13e8dcae2:litellm/utils.py, and the same Initialized Success Callbacks line appears once in proxy_after.log
2. The identical three curls returned 200 with "content":"pong" and total_tokens 17 (chatcmpl-EO75meD2CvOSVRfOnKI4VsAla0DBC, chatcmpl-EO75okmASLhszaJznVZu4WroOe6e1, chatcmpl-EO75rk1vY34vkmMrswePDP6l9qt2d)
3. Counts from proxy_after.log:

$ grep -c "Logging Details LiteLLM-Success Call" proxy_after.log
3
$ grep -c "Logging Details LiteLLM-Async Success Call" proxy_after.log
3
$ grep -n "Logging Details LiteLLM-Success Call" proxy_after.log
406:19:57:22 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
597:19:57:25 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None
760:19:57:28 - LiteLLM:DEBUG: litellm_logging.py:2498 - Logging Details LiteLLM-Success Call: Cache_hit=None

4. One sync success-handler run per request. The async handler count is unchanged at 3, so the fix removed only the duplicate. The original fix(utils): stop wrapper_async submitting the sync success handler twice #41058 run on the staging base with a database attached also showed the spend log count staying at 3 in both arms

Regression test: tests/test_litellm/test_utils.py::test_acompletion_runs_a_custom_logger_sync_logging_hook_exactly_once registers a CustomLogger whose logging_hook records the response id and then blocks on a gate, runs one acompletion through the real logging thread pool, releases the gate, waits for every submitted logging future and asserts the hook saw the response id exactly once. The gate matters because success_handler sets has_run_logging only after the hooks run, so a sequential re-run would be skipped while two concurrent threads both get through, which is the same race the customer hit. On the merge base it fails 3/3 with Left contains one more item: 'chatcmpl-...', on this branch it passes 3/3. tests/test_litellm/test_utils.py, tests/test_litellm/proxy/guardrails/test_deferred_guardrail_logging.py, tests/test_litellm/responses/test_no_duplicate_spend_logs.py and tests/test_litellm/litellm_core_utils/test_litellm_logging.py pass together (731 passed).

Taxonomy audit (A-BB) of the diff: B6 is the defect fixed (the same handler released twice). C1-C7 not applicable: every caller of _dispatch_success_logging still gets exactly one sync submission, including the is_litellm_internal_call, is_completion_with_fallbacks and deferred-guardrail branches. F3: streaming is a separate path (dispatch_success_handlers in streaming_handler.py) and is written into the scope above rather than changed. T4: the test wraps executor.submit only to collect the futures it needs to wait on; the real thread pool and the real success_handler run, and the assertion is on the callback the user configured. T5: success_callback is set through monkeypatch and restored. H2: no comments added.

Type

🐛 Bug Fix

Caveats (if any)

Low

• Streaming async logging is a different code path and was not changed here
• Live proof used a no-op callback; the observable is the per-request sync handler count in the debug log
• Replaces fix(utils): stop wrapper_async submitting the sync success handler twice #41058, which merged into the retired litellm_internal_staging branch and never reached main

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

---

Note

Medium Risk
Touches core request-completion logging for all async wrapper paths; wrong deduplication could drop sync callbacks, though the remaining dispatch in _dispatch_success_logging preserves the intended single run.

Overview
Fixes double execution of the sync success logging path for non-streaming async calls (acompletion, etc.). Successful async requests were running legacy success_callback handlers and related sync logging twice, often from two thread-pool workers on the same logging object.

The duplicate came from _client_async_logging_helper calling handle_sync_success_callbacks_for_async_calls after _dispatch_success_logging had already submitted the same sync pipeline. This change removes that second call from the helper so it only enqueues the async logging worker (async_success_handler).

Adds test_acompletion_runs_a_custom_logger_sync_logging_hook_exactly_once, which gates a CustomLogger sync hook and asserts it sees one response id per acompletion.

^{Reviewed by Cursor Bugbot for commit d13e8dc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Link to Devin session: https://app.devin.ai/sessions/fc8efa80ddc344a09d653fd7c038e848
Open in Devin Desktop: https://app.devin.ai/desktop/session/fc8efa80ddc344a09d653fd7c038e848?variant=devin
Requested by: @yassin-berriai

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_fix_wrapper_async_double_sync_success_handler_main (d13e8dc) with main (b94b8bc)}

[greptile-apps]

Greptile Summary

This PR removes the second synchronous success-handler dispatch from asynchronous, non-streaming request logging while retaining async callback delivery and the direct sync dispatch

• Prevents concurrent duplicate execution of synchronous success callbacks
• Adds a focused regression test using the real logging executor and a gated callback
• Leaves streaming and synchronous request paths unchanged

Confidence Score: 5/5

The PR appears safe to merge because successful non-streaming async calls retain one sync callback dispatch and one async callback dispatch

No actionable failures remain. The removed call duplicated the same sync handler already submitted by _dispatch_success_logging, including normal and deferred paths

Important Files Changed

Filename	Overview
litellm/utils.py	Removes the duplicate sync success-handler submission while preserving the direct sync and async callback paths
tests/test_litellm/test_utils.py	Adds a deterministic regression test that exposes concurrent duplicate sync-handler execution

_{Reviews (1): Last reviewed commit: "fix(utils): stop wrapper_async submittin..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mateo-berri]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit d13e8dc. Configure here.}