karthink/gptel

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.