luigidemasi commented on code in PR #150:
URL: https://github.com/apache/camel-kit/pull/150#discussion_r4452160698
##########
kit/camel-kit-core/src/main/java/org/apache/camel/kit/ship/controller/ShipStageResult.java:
##########
@@ -280,6 +284,26 @@ private static void requireReport(String report) throws
IOException {
utf8(report, MAX_REPORT_BYTES, "stage report");
}
+ private static String extractJsonObject(String text) {
+ if (text == null) {
+ return text;
+ }
+ String stripped = text.strip();
+ if (stripped.startsWith("{")) {
+ return stripped;
+ }
+ Matcher m = JSON_FENCE.matcher(text);
+ if (m.find()) {
+ return m.group(1).strip();
Review Comment:
[P2] Reject conflicting envelopes instead of accepting the first fence
`m.find()` discards everything after the first matching block before
`FAIL_ON_TRAILING_TOKENS` can inspect it. I reproduced a response containing
one valid DESIGN envelope with `materialAmbiguity: false`, followed by a
correction in a second valid fence with `materialAmbiguity: true` and an
unanswered question. The parser accepts the first envelope and loses the
question. Through the real `ShipCoordinator` with the existing Pi RPC fixture,
DESIGN completes and PLAN starts under SMART oversight; the corrected envelope
alone pauses with the question recorded. Before this commit, the conflicting
response failed DESIGN without launching PLAN.
Please accept only an unambiguous single result and reject additional JSON
envelopes, rather than silently choosing one. The brace fallback also turns
`[<valid envelope>]` into an accepted object, so preserve the root-object
check. Add positive wrapped-response tests and negative multi-envelope/array
tests; the ten existing parser tests are unchanged.
_AI-generated by Codex on behalf of @luigidemasi._
##########
kit/camel-kit-core/src/main/java/org/apache/camel/kit/ship/controller/ShipStageResult.java:
##########
@@ -77,8 +80,9 @@ static ShipStageResult parse(Stage stage, String
assistantText) throws IOExcepti
WireResult wire;
boolean legacy = false;
try {
+ String normalized = extractJsonObject(assistantText);
JsonNode document
- = JSON.readValue(utf8(assistantText, MAX_ASSISTANT_BYTES,
"assistant response"), JsonNode.class);
+ = JSON.readValue(utf8(normalized, MAX_ASSISTANT_BYTES,
"assistant response"), JsonNode.class);
Review Comment:
[P2] Validate the complete response before extracting JSON
Moving `utf8()` after extraction removes the 1 MiB and strict-Unicode checks
from the original worker response. A 1,048,725-character response consisting of
prose plus a small valid fence now succeeds; so does a lone surrogate before
the fence. Both were rejected by the previous parser. I also sent the oversized
case through the existing Pi RPC fixture: DESIGN completes at this head,
whereas the previous parser fails it. The transport's separate 16 MiB cap does
not preserve this 1 MiB stage-response limit.
Please validate the original `assistantText` for size and encoding before
trimming or searching it, then parse the selected JSON with the existing strict
settings. Add tests with oversized prose/whitespace and invalid Unicode outside
an otherwise valid envelope.
_AI-generated by Codex on behalf of @luigidemasi._
--
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]
