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
Add time range filtering to conversation and instruction log pages
Implement time range dropdown with predefined options (15 minutes to 1 year)
Update search functionality to include start/end time parameters
Minor UI improvements and code cleanup
Diagram Walkthrough
flowchart LR
A["Time Range Enum"] --> B["Time Range Options"]
B --> C["Convert Time Range Function"]
C --> D["Conversation Page Filter"]
C --> E["Instruction Log Filter"]
D --> F["Search API Calls"]
E --> F
Loading
File Walkthrough
Relevant files
Enhancement
+page.svelte
Add time range filtering to conversation page
src/routes/page/conversation/+page.svelte
Add time range dropdown with default "Last 3 Hours" selection
Integrate time range conversion into search filters
Update search API calls to include startTime/endTime parameters
The convertTimeRange function never sets endTime for most ranges, leading to an open-ended range (now) that may not match backend expectations or cause inconsistent filtering. Confirm API requires explicit endTime and align behavior (e.g., set endTime to current UTC for non-Yesterday ranges).
TimeRange enum uses human-readable labels as values. These values are sent around as identifiers and matched in TIME_RANGE_OPTIONS. This couples UI text with logic and localization, risking breakage if labels are translated. Consider stable keys (e.g., LAST_15_MINUTES) and separate display labels.
timeRange is added to searchOption and used to compute innerTimeRange, but URL/query param sync and initial default handling might be inconsistent. Ensure timeRange is included in setUrlQueryParams/getPagingQueryParams flow and preserved on navigation to avoid surprising resets.
For relative ranges you only set startTime and omit endTime, which can cause drifting results and inconsistent server filtering. Set endTime explicitly to current time in UTC for all relative ranges, and for Today set endTime to end of day for consistency. This avoids open-ended queries and ensures predictable ranges.
export function convertTimeRange(timeRange) {
let ret = { startTime: null, endTime: null };
-- if (!timeRange) {- return ret;- }+ if (!timeRange) return ret;
const found = TIME_RANGE_OPTIONS.find(x => x.value === timeRange);
- if (!found) {- return ret;- }+ if (!found) return ret;
switch (found.value) {
case TimeRange.Last15Minutes:
case TimeRange.Last30Minutes:
case TimeRange.Last1Hour:
case TimeRange.Last3Hours:
case TimeRange.Last12Hours:
case TimeRange.Last3Days:
case TimeRange.Last7Days:
case TimeRange.Last30Days:
case TimeRange.Last90Days:
case TimeRange.Last180Days:
case TimeRange.LastYear:
ret = {
- ...ret,- // @ts-ignore- startTime: moment().subtract(found.qty, found.unit).utc().format()+ startTime: moment().subtract(found.qty, found.unit).utc().format(),+ endTime: moment().utc().format()
};
break;
case TimeRange.Today:
ret = {
- ...ret,- // @ts-ignore- startTime: moment().startOf('day').utc().format()+ startTime: moment().startOf('day').utc().format(),+ endTime: moment().endOf('day').utc().format()
};
break;
case TimeRange.Yesterday:
ret = {
- ...ret,- // @ts-ignore
startTime: moment().subtract(1, 'days').startOf('day').utc().format(),
- // @ts-ignore
endTime: moment().subtract(1, 'days').endOf('day').utc().format()
};
break;
default:
break;
}
-
return ret;
}
Apply / Chat
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies that not setting endTime for relative time ranges can lead to inconsistent filtering results, and the proposed change makes the time ranges explicit and predictable.
Medium
General
Remove misleading unused fields
Including qty and unit for Today and Yesterday is misleading since they are not used as relative offsets in the switch. Remove unused fields for clarity or ensure consumer logic doesn’t incorrectly rely on them. This reduces risk of misapplication elsewhere.
Why: The suggestion correctly points out that the qty and unit fields for Today and Yesterday are unused in the convertTimeRange function, and removing them improves code clarity and maintainability.
The convertTimeRange function never sets an endTime for most ranges (e.g., Last7Days), implicitly meaning "until now". Confirm backend expects null vs explicit current time, and ensure timezone/format (UTC ISO) matches API requirements to avoid filtering mismatches.
innerTimeRange is derived from searchOption.timeRange, but refreshFilter is only called in certain flows. Changing the time range updates searchOption yet won’t affect results until a manual search; verify UX and consider triggering refresh/search on selection or disabling stale state usage in handleStateSearch.
TIME_RANGE_OPTIONS labels use English strings from TimeRange enum. If UI uses i18n, labels may bypass translation. Consider mapping to translation keys or using $_() at render sites to keep localization consistent.
The convertTimeRange function uses moment().utc().format(), but the UI defaults and API filters may expect local time or ISO with explicit Z; without clear backend contract this can mis-filter records around day boundaries (e.g., Today/Yesterday). Confirm backend expects UTC ISO strings and align semantics for "Today"/"Yesterday" (local vs UTC), otherwise compute start/end in the server’s expected timezone or include timezone in requests.
// In convertTimeRange function// 'Today' is based on the user's local start of daycaseTimeRange.Today:
startTime=moment().startOf('day').utc().format();break;// 'Yesterday' is also based on the user's local timezonecaseTimeRange.Yesterday:
startTime=moment().subtract(1,'days').startOf('day').utc().format();endTime=moment().subtract(1,'days').endOf('day').utc().format();break;
After:
// In convertTimeRange function// 'Today' should be based on UTC start of daycaseTimeRange.Today:
startTime=moment.utc().startOf('day').format();break;// 'Yesterday' should also be based on UTC timezonecaseTimeRange.Yesterday:
startTime=moment.utc().subtract(1,'days').startOf('day').format();endTime=moment.utc().subtract(1,'days').endOf('day').format();break;
Suggestion importance[1-10]: 9
__
Why: This suggestion correctly identifies a critical and subtle bug in timezone handling for date-boundary filters ('Today', 'Yesterday'), which could lead to incorrect data filtering based on the user's local timezone.
High
Possible issue
Normalize and validate time outputs
Ensure the returned date strings are in a stable ISO format without timezone ambiguity. Explicitly use ISO 8601 with 'Z' to avoid parsing issues server-side, and handle invalid units defensively. Also, remove the ts-ignore comments by guarding types at runtime.
export function convertTimeRange(timeRange) {
let ret = { startTime: null, endTime: null };
-- if (!timeRange) {- return ret;- }+ if (!timeRange) return ret;
const found = TIME_RANGE_OPTIONS.find(x => x.value === timeRange);
- if (!found) {- return ret;- }+ if (!found) return ret;++ const toIsoUtc = (m) => m.utc().toDate().toISOString();+ const isValidUnit = (u) => ['minutes','hours','days'].includes(u);
switch (found.value) {
case TimeRange.Last15Minutes:
case TimeRange.Last30Minutes:
case TimeRange.Last1Hour:
case TimeRange.Last3Hours:
case TimeRange.Last12Hours:
case TimeRange.Last3Days:
case TimeRange.Last7Days:
case TimeRange.Last30Days:
case TimeRange.Last90Days:
case TimeRange.Last180Days:
case TimeRange.LastYear:
- ret = {- ...ret,- // @ts-ignore- startTime: moment().subtract(found.qty, found.unit).utc().format()- };+ if (typeof found.qty === 'number' && isValidUnit(found.unit)) {+ ret = {+ ...ret,+ startTime: toIsoUtc(moment().subtract(found.qty, found.unit))+ };+ }
break;
case TimeRange.Today:
ret = {
...ret,
- // @ts-ignore- startTime: moment().startOf('day').utc().format()+ startTime: toIsoUtc(moment().startOf('day'))
};
break;
case TimeRange.Yesterday:
ret = {
...ret,
- // @ts-ignore- startTime: moment().subtract(1, 'days').startOf('day').utc().format(),- // @ts-ignore- endTime: moment().subtract(1, 'days').endOf('day').utc().format()+ startTime: toIsoUtc(moment().subtract(1, 'days').startOf('day')),+ endTime: toIsoUtc(moment().subtract(1, 'days').endOf('day'))
};
break;
default:
break;
}
-
return ret;
}
[To ensure code accuracy, apply this suggestion manually]
Suggestion importance[1-10]: 6
__
Why: The suggestion correctly improves the robustness of the convertTimeRange function by adding runtime validation for qty and unit, and makes the date format more explicit, which are good practices.
Low
General
Remove misleading metadata
Prevent misuse by removing qty/unit metadata for non-relative ranges like "Today" and "Yesterday", which are handled specially. This avoids accidental subtraction logic if the switch is extended and reduces ambiguity.
Why: This is a valid suggestion that improves code clarity and maintainability by removing unused and potentially misleading qty and unit properties for specific time range options.
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
Add time range filtering to conversation and instruction log pages
Implement time range dropdown with predefined options (15 minutes to 1 year)
Update search functionality to include start/end time parameters
Minor UI improvements and code cleanup
Diagram Walkthrough
File Walkthrough
+page.svelte
Add time range filtering to conversation pagesrc/routes/page/conversation/+page.svelte
+page.svelte
Add time range filtering to instruction log pagesrc/routes/page/instruction/log/+page.svelte
enums.js
Add TimeRange enum definitionsrc/lib/helpers/enums.js
conversationTypes.js
Update conversation types for time filteringsrc/lib/helpers/types/conversationTypes.js
instructTypes.js
Update instruction types for time filteringsrc/lib/helpers/types/instructTypes.js
common.js
Implement time range conversion utilitysrc/lib/helpers/utils/common.js
strings
vector-item.svelte
Simplify payload key display formattingsrc/routes/page/knowledge-base/common/vector-table/vector-item.svelte
constants.js
Define time range options constantssrc/lib/helpers/constants.js