fix(agentic): added clarification storage for HITL clarifications#1226
fix(agentic): added clarification storage for HITL clarifications#1226junaid-shirur wants to merge 2 commits intomainfrom
Conversation
junaid-shirur
requested review from
devesh-juspay,
kalpadhwaryu,
shivamashtikar and
zereraz
as code owners
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughRefactors clarification handling and JAF context typing across frontend and backend: clarification options changed from objects to strings and selectedId → selectedOption; JAFAdapterCtx renamed to JAFCtx throughout; in-memory clarification storage and provideClarification-based resumption added; several deprecated tool enum members removed. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Frontend
participant JafStream
participant JAF as JAF Runtime
participant ClarStore as ClarificationStorage
Client->>Frontend: User triggers reasoning
Frontend->>JafStream: start runStream (with clarificationStorage)
JafStream->>JAF: runStream(...)
JAF-->>JafStream: interruption (needs clarification)
JafStream->>Frontend: emit clarification request (options: string[])
Frontend->>Client: show options (raw strings)
rect rgb(200,230,200)
Client->>Frontend: select option (index or custom)
Frontend->>JafStream: send selectedOption (string) / selectedIdValue
JafStream->>ClarStore: store clarification result
JafStream->>JAF: provideClarification(selectedOption)
end
JAF->>JafStream: resumedRunState
JafStream->>JAF: continue streaming
JafStream->>Frontend: stream resumed results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Potential focus areas:
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @junaid-shirur, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on enhancing the agentic system's Human-in-the-Loop (HITL) clarification capabilities by standardizing its storage and simplifying its frontend interaction. It also includes significant refactoring of the JAF context and stream resumption logic, alongside a comprehensive cleanup of unused tool definitions and imports, contributing to a more robust and maintainable codebase. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a significant and beneficial refactoring of the Human-in-the-Loop (HITL) clarification logic. By incorporating an in-memory clarification storage and utilizing the provideClarification helper from the @xynehq/jaf library, the server-side code for resuming agent execution is now much simpler and more maintainable. The changes also include simplifying the data model for clarification options on the frontend and cleaning up deprecated tool definitions, which improves overall code health. My review includes one suggestion to align with React best practices for list keys to prevent potential UI bugs.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
frontend/src/components/EnhancedReasoning.tsx (2)
410-421: Iteration rendering behavior change (no substeps) and icon selectionTwo small behavior notes here:
- Returning early when
!hasSubstepson an iteration means attempts with zero substeps won’t render at all. That’s probably fine (no-op iterations), but worth keeping in mind if upstream ever emits empty iterations you’d still want to expose (e.g., “Attempt 1 started but aborted”).- Passing
toolNameintogetAppIconand using planning/first-step → Brain, then app icon, then tool icon is a clear priority order and matches the new XyneTools/App mappings.No correctness issues, just documenting the intentional UX change around empty iterations.
Also applies to: 518-520
1112-1123: Clarification UI now assumes string options; consider slightly more stable keysUsing
clarificationRequest.options: string[]and passingidxasselectedOptionIdwith the rawoptionstring as the label matches the updated HITL model and the hook’sprovideClarificationsignature. The only minor nit iskey={idx}; if options were ever re-ordered or repeated, you might prefer something likekey={`${idx}-${option}`}for a bit more stability, but it’s not functionally required here.server/shared/types.ts (1)
701-710: XyneTools: new requestUserClarification entry aligns with frontend usageThe trimmed
XyneToolsenum with the newrequestUserClarification = "request_user_clarification"member matches howEnhancedReasoningmaps tool names to icons (including the Brain icon for this one). Assuming usages of the removed members have been cleaned up elsewhere, this looks consistent.server/api/chat/agents.ts (1)
919-921: Eliminate redundant date computation.
dateForAIForAgentStepsduplicates thedateForAIcomputed at line 676 with the sameuserTimezone. Reuse the existingdateForAIvariable to avoid unnecessary computation.Apply this diff:
- const dateForAIForAgentSteps = getDateForAI({ - userTimeZone: userTimezone, - }) - const agentSteps = new AgentSteps({ stream, thinking: thinkingRef, - dateForAI: dateForAIForAgentSteps, + dateForAI: dateForAI, actualModelId: actualModelId || null, })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
frontend/src/components/EnhancedReasoning.tsx(6 hunks)frontend/src/hooks/useChatStream.ts(2 hunks)server/api/chat/agents.ts(12 hunks)server/api/chat/jaf-adapter.ts(2 hunks)server/api/chat/jaf-stream.ts(10 hunks)server/api/chat/mapper.ts(1 hunks)server/shared/types.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (6)
📚 Learning: 2025-08-11T08:44:08.412Z
Learnt from: MayankBansal2004
Repo: xynehq/xyne PR: 719
File: server/api/chat/chat.ts:4023-4029
Timestamp: 2025-08-11T08:44:08.412Z
Learning: In server/api/chat/chat.ts and similar files, MayankBansal2004 prefers not to add explicit type definitions for metadata.usage structures when the receiving array is already typed and default values ensure type safety through the || 0 pattern.
Applied to files:
frontend/src/hooks/useChatStream.tsserver/api/chat/jaf-adapter.tsserver/api/chat/mapper.tsserver/shared/types.ts
📚 Learning: 2025-07-28T12:07:13.546Z
Learnt from: vipul-maheshwari
Repo: xynehq/xyne PR: 686
File: server/utils/chainUtils.ts:65-69
Timestamp: 2025-07-28T12:07:13.546Z
Learning: In the chainUtils.ts file, the correct type for message parameters is `SelectMessage[]` rather than `Message[]` when working with conversation message arrays.
Applied to files:
frontend/src/hooks/useChatStream.ts
📚 Learning: 2025-11-06T09:49:42.273Z
Learnt from: Asrani-Aman
Repo: xynehq/xyne PR: 1163
File: server/api/chat/agents.ts:3941-3991
Timestamp: 2025-11-06T09:49:42.273Z
Learning: In server/api/chat/agents.ts dual RAG path and similar agent message flows, when `agentForDb.appIntegrations` is parsed, the outer function (agents.ts) only needs to extract high-level routing info like `agentAppEnums`. The detailed per-app selections (`selectedItems`) are intentionally extracted inside the inner RAG functions (`generateAnswerFromDualRag`, `UnderstandMessageAndAnswer` in chat.ts) by parsing the `agentPrompt` parameter. This is the established architectural pattern: outer function handles routing, inner function handles detailed selection parsing via `parseAppSelections(agentPromptData.appIntegrations)` and passes `selectedItem` to `searchVespaAgent` for per-app item scoping.
Applied to files:
server/api/chat/mapper.tsserver/api/chat/agents.ts
📚 Learning: 2025-05-28T10:47:41.020Z
Learnt from: naSim087
Repo: xynehq/xyne PR: 484
File: server/integrations/google/sync.ts:222-222
Timestamp: 2025-05-28T10:47:41.020Z
Learning: The functions `handleGoogleDriveChange` and `getDriveChanges` in `server/integrations/google/sync.ts` are intentionally exported for future changes, even though they are not currently being imported by other modules.
Applied to files:
server/api/chat/mapper.ts
📚 Learning: 2025-06-16T11:56:22.752Z
Learnt from: oindrila-b
Repo: xynehq/xyne PR: 545
File: server/integrations/google/index.ts:137-145
Timestamp: 2025-06-16T11:56:22.752Z
Learning: In server/integrations/google/index.ts, both Logger (base logger) and loggerWithChild (factory for email-scoped child loggers) are intentionally maintained to handle different logging scenarios - one for when email context is not available and one for when it is available.
Applied to files:
server/api/chat/mapper.ts
📚 Learning: 2025-05-28T10:55:46.701Z
Learnt from: naSim087
Repo: xynehq/xyne PR: 484
File: server/integrations/google/gmail-worker.ts:293-294
Timestamp: 2025-05-28T10:55:46.701Z
Learning: There are two separate `parseMail` functions in the codebase: one in `server/integrations/google/gmail-worker.ts` with signature `(email, gmail, client, userEmail)` returning `{ mailData, insertedPdfCount, exist }`, and another in `server/integrations/google/gmail/index.ts` with signature `(email, gmail, userEmail, client, tracker?)` returning `{ mailData, exist }`. Each file calls its own local version correctly.
Applied to files:
server/api/chat/mapper.ts
🧬 Code graph analysis (1)
server/api/chat/jaf-adapter.ts (1)
frontend/src/components/workflow/Types.ts (1)
Tool(58-63)
🔇 Additional comments (14)
server/api/chat/mapper.ts (1)
33-33: LGTM! Clean import optimization.The import has been appropriately streamlined to include only
Apps, which is the only type from this module used in the file (consistently asApps.Githubthroughout). This reduces the import surface and improves code clarity.frontend/src/hooks/useChatStream.ts (1)
33-38: Clarification request/response wiring looks consistent with backend changes
ClarificationRequest.optionsasstring[]and theClarificationProvidedhandler parsing{ clarificationId, selectedOption }align with the new JAF-side payload (options: string[]andselectedOption), and state flags (waitingForClarification,clarificationRequest,isStreaming) are cleared in a strictly idempotent way from both the SSE handler andprovideClarification. I don’t see correctness issues here.Also applies to: 652-659
frontend/src/components/EnhancedReasoning.tsx (1)
206-228: Reasoning step enhancement and tool name propagation look soundThe added
isToolStep && step.toolNamebranch that hoists the tool name to the iteration and backfills existing substeps withoutapp/toolNamegives you more consistent icons and metadata without changing the external step shape. Normalizing consolidated summary steps to set bothstepSummaryandaiGeneratedSummaryfrom whichever is present also keeps downstream display logic simple. I don’t see any functional regressions in this parsing path.Also applies to: 266-272
server/api/chat/jaf-adapter.ts (1)
11-21: JAFCtx and Tool generics update are consistent and non-breakingDefining
JAFCtxhere and switchingToolSchemaParametersandbuildMCPJAFToolstoTool<unknown, JAFCtx>keeps the MCP/JAF adapter aligned with the rest of the JAFCtx migration. Sinceexecutedoesn’t inspectcontext, this is a pure typing/interop change with no runtime impact.Also applies to: 67-71
server/shared/types.ts (1)
118-126: UserMetadata re-export tweak is benignAdding the trailing comma on
UserMetadatain the schema export is syntactic only; the re-exported type surface is unchanged.server/api/chat/jaf-stream.ts (3)
37-45: JAFCtx migration and runStream generics are coherentSwitching
JafStreamertoJAFRunState<JAFCtx>,JAFRunConfig<JAFCtx>,baseCtx: JAFCtx, andrunStream<JAFCtx, string>lines up cleanly with the newJAFCtxdefinition injaf-adapter.tsand keeps the JAF context typing uniform across adapter, agents, and stream. Since the context isn’t manipulated here beyond being passed through to tools/fallback, this is a safe type-level refactor.Also applies to: 50-56, 99-104, 138-154
176-213: Improved telemetry and tool result messaging around tool callsThe added span attributes (
tool_calls_count, per-calltool_selectionspan,image_citations_count) and the newtoolStatusderivation intool_call_endare all robust:
toolStatusis clamped to"completed" | "failed" | "in_progress", with any unexpected string or non-string defaulting to"completed", which keeps it compatible with thestatustype on reasoning steps.contextsLengthread fromtoolContextsMap(defaulting to 0) is safely folded intoresultSummaryanditemsFound.These are good observability improvements without behavior risk.
Also applies to: 230-247, 316-323
400-421: Verify JAF API contract for clarification third parameterThe review comment's concern appears valid but cannot be definitively resolved without access to the
@xynehq/jafpackage documentation. Here's what the codebase shows:
selectedIdValueat line 636–637 is computed asselectedOption.customInput || selectedOption.selectedOption- However, the
selectedOptionobject also contains anselectedOptionIdfield (per the type definition at server/api/chat/jaf-stream.ts:563–567)- The variable name suggests an ID is expected, but the value passed is text (the option label or custom input), not the ID
Public documentation for
@xynehq/jaf.provideClarificationis not available in search results, and no test files in the repository demonstrate the intended usage pattern.You should verify: Does
provideClarification's third parameter expect the selected option's ID (fromselectedOptionId), or the value/text (fromselectedOptionorcustomInput)? If it expects the ID, line 636–637 should be corrected to passselectedOption.selectedOptionId. This applies to both code locations mentioned in the review (lines 400–421 and 606–647).server/api/chat/agents.ts (6)
155-155: LGTM: Import additions for clarification storage and context type.The new imports support the HITL clarification storage functionality and the JAFCtx type refactor.
Also applies to: 162-162
1381-1412: LGTM: Tool execution context properly updated for new JAF structure.The
onAfterToolExecutioncallback correctly handles the updated context structure withstate: JAFRunState<JAFCtx>and safely accesses the status with appropriate type handling.
1501-1501: LGTM: Span variable declaration for JAF streaming.The
turnSpanvariable is properly declared and passed toJafStreamerfor span management during JAF execution.
1299-1299: JAFCtx type refactor verified as complete across all related modules.The type rename from
JAFAdapterCtxtoJAFCtxis consistent throughout the file and properly propagated across jaf-adapter.ts and jaf-stream.ts with no remaining legacy references.
327-333: No action required—all call sites have been properly updated.The
logAndStreamReasoningmethod signature now includes a seconduserQueryparameter, and verification confirms all 14 call sites acrossserver/api/chat/agents.tsandserver/api/chat/jaf-stream.tshave been updated to pass the required second argument.
1369-1380: No issues found. The in‑memory providers in @xynehq/jaf are intended for development/testing and are cleaned up by normal GC; there's no required external cleanup API to call. TheclarificationStoragecreated at line 1371 requires no explicit disposal, and the current implementation is correct.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
server/api/chat/agents.ts (1)
1349-1356: Simplify the agenticModelId logic for maintainability.The nested ternary operators make this logic difficult to read and verify. Consider refactoring to use explicit if-else statements or extracting the logic into a helper function.
Apply this diff to improve readability:
- const agenticModelId: Models = - actualModelId === defaultBestModelAgenticMode || - actualModelId === defaultBestModel - ? (actualModelId as Models) - : defaultBestModelAgenticMode && - defaultBestModelAgenticMode !== ("" as Models) - ? (defaultBestModelAgenticMode as Models) - : defaultBestModel + // Use actualModelId if it's already one of the agentic models + let agenticModelId: Models + if (actualModelId === defaultBestModelAgenticMode || + actualModelId === defaultBestModel) { + agenticModelId = actualModelId as Models + } else if (defaultBestModelAgenticMode && + defaultBestModelAgenticMode !== ("" as Models)) { + agenticModelId = defaultBestModelAgenticMode as Models + } else { + agenticModelId = defaultBestModel + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
server/api/chat/agents.ts(13 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-06T09:49:42.273Z
Learnt from: Asrani-Aman
Repo: xynehq/xyne PR: 1163
File: server/api/chat/agents.ts:3941-3991
Timestamp: 2025-11-06T09:49:42.273Z
Learning: In server/api/chat/agents.ts dual RAG path and similar agent message flows, when `agentForDb.appIntegrations` is parsed, the outer function (agents.ts) only needs to extract high-level routing info like `agentAppEnums`. The detailed per-app selections (`selectedItems`) are intentionally extracted inside the inner RAG functions (`generateAnswerFromDualRag`, `UnderstandMessageAndAnswer` in chat.ts) by parsing the `agentPrompt` parameter. This is the established architectural pattern: outer function handles routing, inner function handles detailed selection parsing via `parseAppSelections(agentPromptData.appIntegrations)` and passes `selectedItem` to `searchVespaAgent` for per-app item scoping.
Applied to files:
server/api/chat/agents.ts
🧬 Code graph analysis (1)
server/api/chat/agents.ts (7)
server/utils/index.ts (1)
getDateForAI(3-29)server/api/chat/agentSteps.ts (1)
AgentSteps(32-354)server/api/chat/jaf-adapter.ts (1)
JAFCtx(11-16)server/api/chat/jaf-provider.ts (1)
makeXyneJAFProvider(36-236)server/ai/agentPrompts.ts (1)
hitlClarificationDescription(2316-2340)server/api/chat/types.ts (1)
MinimalAgentFragment(95-101)server/shared/types.ts (1)
Span(57-57)
🪛 GitHub Actions: TypeScript Build Check
server/api/chat/agents.ts
[error] 155-155: Module '"@xynehq/jaf"' has no exported member 'createInMemoryClarificationStorage'.
[error] 1391-1391: Object literal may only specify known properties, and 'clarificationStorage' does not exist in type 'RunConfig'.
🔇 Additional comments (4)
server/api/chat/agents.ts (4)
1303-1303: LGTM: JAFCtx type refactor is consistent.The refactor from
JAFAdapterCtxtoJAFCtxis applied consistently throughout the file, and the type is correctly imported from@/api/chat/jaf-adapter. The type definition exists and matches the usage pattern.Also applies to: 1357-1357, 1364-1364, 1366-1366, 1370-1370, 1398-1398
1410-1423: LGTM: Formatting improvements maintain logic.The reformatting of the attribute setting code improves readability while preserving the original logic. The confidence calculation and attribute assignments remain functionally identical.
155-155: The JAF library exportscreateInMemoryProvider, notcreateInMemoryClarificationStorage. The code at line 155 is importing the wrong function name.Correct the import statement: Replace
createInMemoryClarificationStoragewithcreateInMemoryProviderLine 155 should import:
createInMemoryProvider,Line 1382 should call:
const clarificationStorage = createInMemoryProvider()⛔ Skipped due to learnings
Learnt from: Asrani-Aman Repo: xynehq/xyne PR: 1163 File: server/api/chat/agents.ts:3941-3991 Timestamp: 2025-11-06T09:49:42.273Z Learning: In server/api/chat/agents.ts dual RAG path and similar agent message flows, when `agentForDb.appIntegrations` is parsed, the outer function (agents.ts) only needs to extract high-level routing info like `agentAppEnums`. The detailed per-app selections (`selectedItems`) are intentionally extracted inside the inner RAG functions (`generateAnswerFromDualRag`, `UnderstandMessageAndAnswer` in chat.ts) by parsing the `agentPrompt` parameter. This is the established architectural pattern: outer function handles routing, inner function handles detailed selection parsing via `parseAppSelections(agentPromptData.appIntegrations)` and passes `selectedItem` to `searchVespaAgent` for per-app item scoping.
328-334: Signature verification confirms all calls are correct. ThelogAndStreamReasoningmethod signature is properly defined as(reasoningStep: AgentReasoningStep, userQuery: string): Promise<void>, and all calls throughout the file (lines 328-334, 442-448, 934-940, 1111-1117, 1255-1270, 1280-1287) pass the appropriate object shapes matching theAgentReasoningStepunion type, withmessagecorrectly provided as the second parameter.
| // Create clarification storage for HITL | ||
| const clarificationStorage = createInMemoryClarificationStorage() | ||
|
|
||
| const runCfg: JAFRunConfig<JAFCtx> = { | ||
| agentRegistry, | ||
| modelProvider, | ||
| maxTurns: 10, | ||
| modelOverride: agenticModelId, | ||
| allowClarificationRequests: true, | ||
| clarificationDescription: hitlClarificationDescription, | ||
| clarificationStorage, |
There was a problem hiding this comment.
🧩 Analysis chain
Critical: clarificationStorage property not recognized in RunConfig type.
The pipeline indicates that clarificationStorage does not exist in RunConfig<JAFCtx>. This suggests either:
- The
@xynehq/jaflibrary version doesn't support this property yet - The property name or type is incorrect
- The library needs to be updated
This blocks compilation.
Verify the JAF library version and RunConfig type definition:
🏁 Script executed:
#!/bin/bash
# Check installed JAF version
npm list @xynehq/jaf
# Search for RunConfig type definition in node_modules
fd -t f "index.d.ts" node_modules/@xynehq/jaf -x cat {} | grep -A 20 "interface RunConfig" || echo "Type definition not found in node_modules"
# Check if clarificationStorage is mentioned anywhere in JAF types
fd -t f -e ts -e d.ts . node_modules/@xynehq/jaf -x rg "clarificationStorage|ClarificationStorage" {}Length of output: 297
🏁 Script executed:
#!/bin/bash
# Check package.json for JAF dependency
grep -A 2 -B 2 "@xynehq/jaf" package.json || echo "JAF not found in package.json"
# Look at imports in agents.ts
head -50 server/api/chat/agents.ts | grep -E "import|from" | head -20
# Search for RunConfig definition in the codebase
rg -n "interface RunConfig|type RunConfig" --type ts --type tsx
# Look for createInMemoryClarificationStorage import/definition
rg -n "createInMemoryClarificationStorage" --type ts --type tsx -B2 -A2
# Search for clarificationStorage references
rg -n "clarificationStorage" server/api/chat/agents.ts -B2 -A2Length of output: 1202
🏁 Script executed:
#!/bin/bash
# Search for imports around createInMemoryClarificationStorage
rg -n "createInMemoryClarificationStorage|ClarificationStorage" --type ts -A2 -B2
# Look for JAFRunConfig type and imports
rg -n "JAFRunConfig|from.*jaf" --type ts -A1 -B1
# Get more context around line 1380-1391 in agents.ts
sed -n '1370,1400p' server/api/chat/agents.ts
# Check all imports at top of agents.ts
sed -n '1,100p' server/api/chat/agents.ts | rg "import"Length of output: 8480
🌐 Web query:
@xynehq/jaf clarificationStorage JAFRunConfig property
💡 Result:
I can't find any reference to a RunConfig property named clarificationStorage in the public JAF docs or repo snapshots. Do you want me to:
- search the xynehq/jaf GitHub repo (or a specific branch/file) for "clarificationStorage", or
- look for a similarly named property (e.g., clarification, clarificationStore) in the docs/code?
Tell me which you'd prefer and I'll run the search and cite the results.
🌐 Web query:
xynehq/jaf GitHub RunConfig interface type definition
💡 Result:
The RunConfig type (TypeScript) in xynehq/jaf is:
export type RunConfig = {
readonly agentRegistry: ReadonlyMap<string, Agent<Ctx, any>>;
readonly modelProvider: ModelProvider;
readonly maxTurns?: number;
readonly modelOverride?: string;
readonly initialInputGuardrails?: readonly Guardrail[];
readonly finalOutputGuardrails?: readonly Guardrail[];
readonly onEvent?: (event: TraceEvent) => void;
readonly memory?: MemoryConfig;
readonly conversationId?: string;
}. [1][2]
Sources:
- JAF Core Concepts — RunConfig type definition. [1]
- JAF Server API docs (ServerConfig referencing RunConfig). [2]
Critical: clarificationStorage and related properties are not supported in the current JAFRunConfig type.
The RunConfig type from @xynehq/jaf does not include clarificationStorage, allowClarificationRequests, clarificationDescription, or onAfterToolExecution properties. The code at lines 1385-1391 attempts to add these unsupported properties, which will cause a TypeScript compilation error.
Either use a different API for HITL configuration, downgrade to a JAF version that supports these properties, or remove these properties if they're not required.
🧰 Tools
🪛 GitHub Actions: TypeScript Build Check
[error] 1391-1391: Object literal may only specify known properties, and 'clarificationStorage' does not exist in type 'RunConfig'.
🤖 Prompt for AI Agents
In server/api/chat/agents.ts around lines 1381-1391, the JAFRunConfig type from
@xynehq/jaf does not include clarificationStorage, allowClarificationRequests,
clarificationDescription, or onAfterToolExecution, so adding them causes a
TypeScript error; fix it by either (A) removing those unsupported properties
from runCfg and moving HITL-specific setup into the correct HITL API call or
separate config object accepted by the library, or (B) if you intentionally need
to keep them, define and use a new interface that extends JAFRunConfig with
these HITL fields (or cast the config to unknown as any) and ensure the runtime
consumer expects that extended shape, or (C) update/downgrade @xynehq/jaf to a
version that exposes these properties and adjust imports accordingly.
1 participant
Description
Testing
Additional Notes
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
✏️ Tip: You can customize this high-level summary in your review settings.