You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The local showAdvSearch, items, and operator props are mutated internally (e.g., reset() sets items = [...]) without syncing to a parent unless bound; ensure parent bindings are always present or emit changes to avoid stale state when this component is used elsewhere.
function reset() {
items= [{ uuid: uuidv4(), key: '', value: '', checked: true }];
}
/**
* @param {any} e
* @param {number} idx
*/
function toggleItem(e, idx) {
const found =items.find((_, index) =>index===idx);
if (found) {
found.checked=e.target.checked;
items=items.map((x, index) => {
returnindex===idx? { ...found } :x;
});
}
}
async function addItem() {
items= [
...items,
{ uuid: uuidv4(), key: '', value: '', checked: true }
];
// Wait for DOM to update, then scroll to bottomawaittick();
if (scrollContainer) {
scrollContainer.scrollTop=scrollContainer.scrollHeight;
}
}
/**
* @param {number} idx
*/
function removeItem(idx) {
if (disabled) return;
items=items.filter((_, index) =>idx!==index);
}
/**
* @param {any} e
* @param {number} idx
* @param {string} key
*/
function changeItem(e, idx, key) {
const found =items.find((_, index) =>index===idx);
if (found) {
if (key==='key') {
found.key=e.target.value;
} elseif (key==='value') {
found.value=e.target.value;
}
items=items.map((x, index) => {
returnindex===idx? { ...found } :x;
});
}
}
/**
* @param {any} e
*/
function changeLogicalOperator(e) {
handleConfirm sends payload separately while also spreading text/answer into data. The caller updates only found.data with newItem.payload merged, but existing data keys not in payload are replaced; verify server/consumer expectations to avoid losing unrelated fields.
Replaced included_payloads/search_pairs with fields/filter_groups. Ensure backend supports these fields across both paging and search endpoints; otherwise calls may fail or silently ignore filters.
The new client API switches from search_pairs to filter_groups with filter_operator and filters, but there’s no visible normalization/validation to ensure operators and keys map to what the backend expects (e.g., enum values, required fields, empty groups). Add a central validator/mapper that guarantees only supported operators are sent, trims/removes empty filters, and converts UI state into the exact backend contract to prevent silent no-op searches or 400s across both pages.
function buildSearchFilterGroups(items) {
/**@type{any[]}*/let groups = [];
if (textSearch&&!!text) {
groups= [ ...groups, { filter_operator: 'or', filters: [
{ key: KnowledgePayloadName.Text, value: text },
{ key: KnowledgePayloadName.Answer, value: text }
] } ];
}
... (clipped8lines)
Solution Walkthrough:
Before:
function buildSearchFilterGroups(items) {
let groups = [];
if (textSearch&&!!text) {
// ... adds a group for text search
}
if (isAdvSearchOn&&items?.length>0) {
const validItems =items.filter(x=>x.checked&&!!util.trim(x.key) &&!!util.trim(x.value))
.map(x=> ({ key: util.trim(x.key), value: util.trim(x.value) }));
// This can add a group with an empty `filters` array if `validItems` is empty.groups= [ ...groups, { filter_operator: selectedOperator, filters: validItems } ];
}
returngroups;
}
After:
// In a shared utility file
function createFilterGroups(textSearch, text, isAdvSearchOn, items, selectedOperator) {
const groups = [];
if (textSearch&&text) {
// ... adds a group for text search
}
if (isAdvSearchOn) {
const validFilters =items
.filter(item=>item.checked&&item.key&&item.value)
.map(item=> ({ key: item.key.trim(), value: item.value.trim() }));
if (validFilters.length>0) {
groups.push({ filter_operator: selectedOperator, filters: validFilters });
}
}
returngroups;
}
Suggestion importance[1-10]: 8
__
Why: The suggestion correctly identifies that the buildSearchFilterGroups function, duplicated in two files, lacks validation for empty filter sets, which could lead to incorrect API requests and search results.
Medium
Possible issue
✅ Use unified data sourceSuggestion Impact:The commit removed reliance on dataSource from newItem.data in refreshItems and shifted dataSource handling to e.payload elsewhere, aligning with the suggestion’s goal to use a unified source and avoid mixing data and payload. It also updated confirmEdit to consistently use e.payload.dataSource, reinforcing the unified approach.
refreshItems reads newItem.payload while the edit modal now merges payload into data. This causes updated fields to be dropped from the UI. Read from newItem.data only to keep behavior consistent regardless of where payload lives.
Why: The suggestion correctly points out that refreshItems merges newItem.data and newItem.payload, but the updateVectorKnowledgeData call in confirmEdit uses a confusing mix of properties from e.data and e.payload. The proposed change simplifies refreshItems to use a single data source, which would be consistent if the data structure from the modal were also simplified, thus preventing potential bugs.
Medium
Consolidate item update source
As with documents, mixing data and payload breaks updates if the modal merges payload into data. Consolidate by deriving from newItem.data only to ensure the UI reflects all fields, including added payload entries.
Why: Similar to the previous suggestion, this one correctly identifies an inconsistent data handling pattern. The refreshItems function merges newItem.data and newItem.payload, while the confirmEdit function also manually combines properties. The suggestion to consolidate the update source in refreshItems is a good step toward simplifying the logic and making it more robust.
Medium
Merge payload into data
Merging payload into a separate payload property may be ignored downstream where data is expected to contain all fields. Either integrate the payload into data or ensure all consumers use payload. To prevent data loss, merge the computed payload back into data consistently with readers.
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies that passing data and payload separately from the modal leads to more complex handling in the parent components, which currently have to merge them back together. Unifying them into a single data object in the modal improves code clarity and maintainability.
The edit modal constructs a new payload object and assigns it to e.payload, but the UI also displays data from item.data. This may cause divergence between data and payload fields after update (e.g., some non-text fields moved to payload and removed from data). Verify backend contract and ensure consistent rendering after edits.
Clickable icons for remove actions use suppressed a11y rules and lack keyboard handlers. Consider adding key handlers and aria labels for better accessibility.
Advanced filter groups are always passed even when empty, and selectedOperator defaults to 'or'. Confirm backend handling of empty groups and operator casing; ensure that adding text search also sets proper payload keys and that limit/fields are aligned with API expectations.
The PR introduces new request/response shapes (filter_groups, fields, vector_dimension) and shifts edited data into payload, but updates appear only in frontend types and UI. Ensure backend APIs, persistence, and existing consumers are aligned to avoid runtime failures (e.g., searches ignoring filters, edits dropping fields). Provide migration/compat layer so older data with vector length but no vector_dimension and existing search_pairs/included_payloads paths still work.
// Old search logicfunctiongetKnowledgeListData(params){constsearchPairs=buildSearchPairs(params);constfilter={// ...search_pairs: searchPairs};callApi(filter);}// Old update logicfunctionconfirmEdit(event){const{ text, ...payload}=event.data;updateApi(event.id,text,payload);}
After:
// New search logicfunctiongetKnowledgeListData(params){constfilter={// ...filter_groups: params.filterGroups};callApi(filter);}// New update logicfunctionconfirmEdit(event){const{ data, payload }=event;updateApi(event.id,data.text,payload);}
Suggestion importance[1-10]: 9
__
Why: This suggestion correctly identifies a critical architectural flaw where frontend data contracts have been significantly altered without any corresponding backend changes in the PR, which will likely break core search and edit functionality.
High
Possible issue
Avoid invalid/duplicate payload fields
Ensure that excluded payload keys are not duplicated between data and payload. Currently answer is added to data for all collection types, which is invalid for document collections and may override or duplicate fields. Conditionally include answer only for Q&A collections and keep other extra fields strictly in payload.
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies that unconditionally adding answer to data is problematic for document collections and proposes a valid conditional logic to prevent this potential issue.
Medium
General
Remove redundant change handler
Using both bind:group and an explicit on:change handler can cause double updates or race conditions. Since you already bind operator, remove the manual on:change handler and rely on binding to keep state consistent. This avoids redundant state updates.
Why: The suggestion correctly points out that using both bind:group and on:change is redundant, and removing the on:change handler is a valid simplification for better code clarity.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Type
Enhancement
Description
Refine knowledge base search with advanced filtering
Add reasoning effort level to agent LLM config
Enhance vector knowledge editing with payload support
Improve UI scrolling and styling
Diagram Walkthrough
File Walkthrough
1 files
Add styling for tooltips and scrollable containers8 files
Add reasoning effort level configuration optionRefactor advanced search with dynamic filtersAdd payload editing functionality to modalIntegrate advanced search with filter groupsAdd advanced search to Q&A knowledgeAdd reasoning effort level enum valuesAdd reasoning effort level to type definitionUpdate knowledge types for filter groups2 files
Update vector dimension display logicFix text splitting logic condition