Response Error in certain org-buffer when doing gptel-send
Closed this issue · 5 comments
Bug Description
In certain buffer formattings doing M-x gptel-send
fails as
Querying Claude...
Claude error: (HTTP/2 400) messages.6: all messages must have non-empty content except for the optional final assistant message
gptel response error: (((HTTP/2 400) invalid_request_error) messages.6: all messages must have non-empty content except for the optional final assistant message) nil
outputted to *Messages*
buffer.
Backend
Anthropic
Steps to Reproduce
Insert the following contents
:PROPERTIES:
:GPTEL_BACKEND: Claude
:GPTEL_MODEL: claude-3-sonnet-20240229
:GPTEL_SYSTEM: You are a large language model and a careful programmer. Provide code and only code as output without any additional text, prompt or note.\n\nWhen generating C code use as modern constructs as possible including the ones part of the new upcoming C2Y standard that are available in the most recent stable version of Clang.\n\nIn C-like languages like C, C++ and D:\n\n- Formatting should use K&R style with tab character for indentation.\n- Variables that aren't mutated after they have been initialized (read-only)\n should be qualified with the attribute `const` as in `const int x = 42`.\n
:GPTEL_BOUNDS: ((1165 . 1248) (1288 . 1353) (1387 . 1401) (1403 . 1424) (1426 . 1454) (1456 . 1472) (1474 . 1475) (1476 . 1485) (1487 . 1488) (1489 . 1500) (1502 . 1505) (1507 . 1552) (1554 . 1578) (1580 . 1599) (1601 . 1637) (1639 . 1664) (1666 . 1674) (1676 . 1703) (1705 . 1709) (1711 . 1715) (1717 . 1749) (1751 . 1766) (1768 . 1771) (1773 . 1819) (1821 . 1840) (1842 . 1889) (1891 . 1931) (1933 . 1974) (1976 . 1979) (1981 . 1992))
:END:
** Write an identity function in C.
#+begin_src c
void* identity(const void* input) {
return (void*)input;
}
#+end_src
*** Write an identity function in D.
#+begin_src d
T identity(T)(T value) {
return value;
}
#+end_src
*** Write me a quicksort in C.
#+begin_src c
#include <stddef.h>
void swap(int* a, int* b) {
int temp = *a;
,*a = *b;
,*b = temp;
}
int partition(int* arr, int low, int high) {
int pivot = arr[high];
int i = low - 1;
for (int j = low; j < high; j++) {
if (arr[j] <= pivot) {
i++;
swap(&arr[i], &arr[j]);
}
}
swap(&arr[i + 1], &arr[high]);
return i + 1;
}
void quicksort(int* arr, int low, int high) {
if (low < high) {
int pivot_index = partition(arr, low, high);
quicksort(arr, low, pivot_index - 1);
quicksort(arr, pivot_index + 1, high);
}
}
#+end_src
*** Write me an identity function in D.
in a buffer named sample.gptel.org
to the end of it and then do gptel-send
.
Additional Context
GNU Emacs 31.0.50 on Ubuntu 24.04.
Log Information
No response
Backtrace
No response
Please make sure gptel is up to date. This error was fixed a few weeks ago.
Ok, thanks. I believe I had an up-to-date version. I update my elpa packages once every day. Closing this for now. And will reopen if the problem pops up again.
FWIW, I have also been experiencing this issue (with an up-to-date version of gptel
). Strangely, in my case it is fixed by closing the org buffer and reopening the file it was visiting (NB: calling revert-buffer
is not enough: the buffer has to be killed.)
There are other issues with Claude, though, including truncated responses and non-responses. I don’t know if you are already aware of these; if not, I can provide more details if needed and/or open a new issue. (It’s not clear to me whether these different issues are part of a general problem with Claude, so I thought I should just mention it here.)
There are other issues with Claude, though, including truncated responses and non-responses. I don’t know if you are already aware of these; if not, I can provide more details if needed and/or open a new issue. (It’s not clear to me whether these different issues are part of a general problem with Claude, so I thought I should just mention it here.)
I'm not aware of these problems. It's possible the parser has some edge cases. If you can recreate these with logging turned on (setq gptel-log-level 'info)
, we can compare the HTTP response log to what was printed in the buffer and identify any issues. Please create a new issue if you find something in this regard.
Strangely, in my case it is fixed by closing the org buffer and reopening the file it was visiting (NB: calling
revert-buffer
is not enough: the buffer has to be killed.)
That's also very strange. When you get this error, could you do a dry-run and look at the structure that's sent? It'll be useful to pin down how exactly an empty message is added.