Add support for OpenAI Developer message #3089
Conversation
andresssantos
commented
May 10, 2025
•
andresssantos
commented
- Included DEVELOPER in the MessageType enum
- Created DeveloperMessage class with constructors, copy(), mutate(), and builder methods
- Updated AbstractMessage constructor to accept DEVELOPER messages without validation errors
- Updated ChatModel and ChatClient methods to support DEVELOPER message type
- Developed unit tests for DeveloperMessage, validating exception cases and proper inclusion in prompts
…s, and tests - Included DEVELOPER in the MessageType enum with value "developer" - Updated AbstractMessage constructor to accept DEVELOPER messages without validation errors - Created DeveloperMessage class with constructors, copy(), mutate(), and builder methods - Added validation to ensure textContent is not null or empty when creating DeveloperMessage - Modified message creation methods (e.g., Neo4jChatMemoryRepositoryIT) to handle MessageType.DEVELOPER - Updated ChatModel and ChatClient methods to support DEVELOPER message type - Developed unit tests for DeveloperMessage, validating exception cases and proper inclusion in prompts - Adjusted existing SystemMessage validation tests to include DEVELOPER for consistency Signed-off-by: Andres da Silva Santos <40636137+andresssantos@users.noreply.github.com>
Signed-off-by: Andres da Silva Santos <40636137+andresssantos@users.noreply.github.com>
Signed-off-by: Andres da Silva Santos <40636137+andresssantos@users.noreply.github.com>
andresssantos
force-pushed
the
chatclient-developer-message
branch
from
a59a9dd to
1cd337d
Compare
|
related pr : #2864 |
andresssantos
changed the title
|
hi folks. I do appreciate the PR, but I made a mistake in my comments on the other related one, saying that was incomplete. This PR adds non portable 'developer' fluent api methods to the portable chatclient interface and that goes against the portability design idea. These issues require more up front design as they touch large areas of the code. This issue as well as other would be addressed by a 'capability' feature, see #3103 so that can have more information on how to make correct adaptations to various features for specific models. Likely this will live in a sort of options like manner, but again, needs desgin. I'm going to leave this PR open now under 'to discuss` and move it to the post GA time frame. I really love the capabilities (ha ha - no pun intended) of the reasoning models and want to get support for them in a a priority after GA. Too bad it didn't work out before GA. |
|
Thank you for your feedback @markpollack. I agree that implementing a more general solution, such as a "capability" feature, makes more sense in the long run. |
