fix(gateway): stop typing after response delivery

[helix4u]

What does this PR do?

Stops gateway typing indicators immediately after the user-visible response is delivered, before post-delivery hooks and debounce cleanup continue running.

On Discord, the platform adapter keeps a persistent typing task that refreshes the typing endpoint every 12 seconds. The agent path already calls stop_typing() when the model result is ready, but the base adapter's generic _keep_typing() task can still recreate the platform typing loop while the final response is being sent and while post-delivery hooks run. That leaves the user seeing a completed reply while Hermes still appears to be typing.

This change cancels the generic typing task and calls the platform stop_typing() hook immediately after delivery. The existing final cleanup remains in place as a safety net for empty-response, error, cancellation, and late cleanup paths.

Existing related PRs reviewed before opening this:

• fix(gateway): stop typing refresh before first outbound delivery #25210 stops typing before first outbound delivery and includes broader tests.
• fix(gateway): stop typing indicator before final response delivery #29172 implements a broader stream-consumer/final-delivery stop signal.
• fix(discord): stop typing indicator before response delivery #38566 stops Discord typing before response delivery.
• fix(gateway): terminate typing indicator before executing post-delive… #39693 makes a similar post-delivery hook ordering change but does not include a regression test.

Related Issue

N/A - found from local Windows Discord gateway repro.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Security fix
• Documentation update
• Tests (adding or improving test coverage)
• Refactor (no behavior change)
• New skill (bundled or hub)

Changes Made

• gateway/platforms/base.py: stop the generic typing task and the platform typing loop immediately after user-visible delivery, before on_processing_complete hooks and debounce cleanup.
• tests/gateway/test_base_topic_sessions.py: add a regression test proving typing is stopped before the processing-complete hook observes the completed turn.

How to Test

1. Run scripts/run_tests.sh -j 4 tests/gateway/test_base_topic_sessions.py.
2. Run a Discord gateway session.
3. Send a message that takes long enough to show the Discord typing indicator, then confirm the indicator does not keep refreshing after the reply is visible.

Focused local validation:

• venv/Scripts/python.exe -m py_compile gateway/platforms/base.py tests/gateway/test_base_topic_sessions.py
• scripts/run_tests.sh -j 4 tests/gateway/test_base_topic_sessions.py - 11 passed
• Windows AppData install: restarted local gateway and confirmed Discord + Home Assistant connected after the patch.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11 AppData desktop/gateway install

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) - N/A
• I've updated cli-config.yaml.example if I added/changed config keys - N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows - N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide
• I've updated tool descriptions/schemas if I changed tool behavior - N/A

For New Skills

N/A

Screenshots / Logs

Local Windows gateway log showed the user-visible Discord response sent before follow-on cron/background activity continued:

• response ready: platform=discord ... time=319.6s
• [Discord] Sending response ...

The patch moves typing cleanup to immediately after that delivery boundary so post-delivery work cannot keep the Discord typing loop alive.

[liuhao1024]

Verification: looks correct.

The change correctly moves stop_typing / _stop_typing_task to execute before the _run_processing_hook call, so Discord and other platforms stop showing "typing…" as soon as the response is delivered. The hasattr guard handles adapters without a stop_typing method gracefully.

Test test_process_message_background_stops_typing_before_complete_hook verifies the ordering constraint: typing-cancelled and stop-typing both appear before complete in the event sequence. Clean test design with explicit ordering assertions.

[kshitijk4poor]

Thanks for this, and for the careful write-up linking the related PRs.

The post-delivery typing-stop fix has landed on main via #37556 (merged as 6a30cfca8), so I'm closing this as superseded.

For the record on the difference: this PR placed the early _stop_typing_task() inside the try block, ahead of the on_processing_complete hook. Because _stop_typing_task swallows CancelledError, a cancellation landing in that post-delivery window gets eaten and the turn is reported SUCCESS instead of CANCELLED (verified with a control-flow repro: pre-PR CANCELLED, post-PR mislabeled SUCCESS). On Telegram that leaves the in-progress reaction stuck, since it's only cleared on CANCELLED. #37556 avoids this by placing the stop at the top of finally, after the outcome is already decided, and additionally moves the stop ahead of the post-delivery callback plus bounds that callback with a timeout — which also closes the root-cause issue #24971.

Appreciate the contribution — the diagnosis here was sound, it was just the placement that mattered.