Skip to content

fix: use async gptel-request with dedicated Ollama backend - #21

Merged
abdrysdale merged 1 commit into
abdrysdale:mainfrom
barbed-chili-glue:fix/proofreading-cleanup
Aug 21, 2026
Merged

abdrysdale merged 1 commit into
abdrysdale:mainfrom
barbed-chili-glue:fix/proofreading-cleanup

Conversation

@barbed-chili-glue

Copy link
Copy Markdown
Contributor

Summary

  • Replace synchronous gptel-request calls with async callback pattern
  • Capture Ollama backend from existing gptel config into gptel-ollama-backend variable
  • Pass :backend explicitly to gptel-request to avoid routing to Gemini/Together AI
  • Remove duplicate Ollama backend definition

Problem

The proofreading functions used gptel-request synchronously (treating the return value as a string) and did not specify :backend. This caused two errors:

  1. The request went to whatever gptel-backend was currently active (Gemini), not Ollama
  2. gptel-request is asynchronous — the return value is an FSM state object, not a string

Fix

  • gptel-ollama-backend is now set in the gptel :config block by capturing the return value of gptel-make-ollama
  • Both proofreading functions use :backend gptel-ollama-backend and :callback for async response handling

- Replace synchronous gptel-request calls with async callback pattern
- Capture Ollama backend from existing gptel config into gptel-ollama-backend
- Pass :backend explicitly to avoid routing to Gemini/Together AI
- Remove duplicate Ollama backend definition
@abdrysdale
abdrysdale merged commit 26c0c58 into abdrysdale:main Aug 21, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants