search

karthink / gptel

A simple LLM client for Emacs
GNU General Public License v3.0
1.04k stars 111 forks source link

`gptel-send` errors for Claude with `Wrong type argument: stringp, nil` #234

Closed erwald closed 3 months ago

erwald commented 3 months ago

I get the following error when doing gptel-send:

Querying Claude...
error in process sentinel: save-current-buffer: Wrong type argument: stringp, nil
error in process sentinel: Wrong type argument: stringp, nil

My config:

(setq-default gptel-model "claude-3-sonnet-20240229"
              gptel-backend (gptel-make-anthropic "Claude"
                              :stream nil
                              :key (s-trim (with-temp-buffer
                                             (insert-file-contents "~/Documents/doom-config/claude.token")
                                             (buffer-string)))))

I've also tried it with claude-3-opus-20240229, and same issue there.

I know the request is getting through all right, and that there's no error but rather a proper response returned, from looking at the log on the Claude console:

image

So it seems like something is going wrong on the receiving end?

karthink commented 3 months ago

Could you run (setq gptel-log-level 'debug), try using Claude, then pasting the contents of the *gptel-log* buffer here?

Please note: Remove your API key from the buffer before pasting in the output here. The API key is logged with every request.

erwald commented 3 months ago

Weird, today it magically works. Although I do run into #233, i.e. the response misses a character or two up front. Maybe it was something with the API backend being unstable after all?

I think you can close this; I will reopen it and share the debug log if/when the issue returns.

ETA: Thanks for your work on this project btw!

karthink commented 3 months ago

Maybe it was something with the API backend being unstable after all?

I think it's a combination of the API being unstable and gptel not handling errors gracefully. If it doesn't receive an expected response gptel should display a semi-helpful message, not throw an error like it does. It will be easier to fix once we can identify the cause.

I'll close this for now, but if it happens again please try the debugging step I suggested above and reopen this issue.