Ashfaqbs opened a new issue, #1064:
URL: https://github.com/apache/flink-agents/issues/1064

   ### Search before asking
   
   - [x] I searched in the 
[issues](https://github.com/apache/flink-agents/issues) and found nothing 
similar.
   
   ### Description
   
   The project deliberately keeps Java and Python semantically aligned 
(AGENTS.md: "Public API changes must keep Java, Python, and YAML APIs 
semantically aligned"), but drift between the two runtimes keeps surfacing as 
separately-discovered bugs and tech-debt items rather than being caught 
systematically: #936 (non-happy-path response handling diverges between Java 
and Python for OpenAI-family connections), #1055/#1056 (umbrella reviews of API 
consistency for 0.4), #1016 (align Java and Python recovery model), and #687 
(Python-side EventListener still missing to match the Java SDK). Each of these 
was found by manual inspection or by a user hitting the gap in production, not 
by a check that runs on every change.
   
   What value does it bring: a shared, versioned test harness that defines the 
*same* small set of representative agent behaviors — a tool call, a 
structured-output request, an error path, a recovery-after-restart scenario — 
as data-driven fixtures, then runs each fixture against both the Java and the 
Python runtime and diffs the observable outcome (emitted events, final 
ChatMessage/tool outcome shape, error handling). A mismatch fails CI with a 
concrete diff instead of relying on someone noticing behavioral drift after the 
fact.
   
   This complements, rather than duplicates, the ongoing manual audits 
(#1055/#1056/#1016) — it's the regression-prevention layer underneath them, so 
a parity issue those audits already fixed doesn't quietly reopen in a later 
change.
   
   Do you already have a solution in mind: no PR yet — this is a proposal to 
check the direction is one the project wants before committing time to a 
specific harness shape (fixture format, where it lives — `e2e-test/` vs. its 
own module, how much of the outcome-shape comparison can be automated vs. needs 
an explicit per-fixture assertion).
   
   ### Are you willing to submit a PR?
   
   - [ ] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to