Conversation
…18n fixes Server: - Add date range filtering (start_date/end_date/date_field) and pagination to MCP search tool - Add collectionId/collectedAt fields to McpPageItem and all builder paths in McpUtils - Add structured filter fields (contentType, libraryFilter, alreadyRead, searchTitleOnly) to SearchQuery - Add new MCP tools: ListCollections, ListCollectionContent, GetXSaveRules - Refactor McpServerController tool dispatch with getToolArguments/executeTool helpers - Refactor LuceneService search option resolution; add buildSearchDateRangeQuery Extension: - Add AbortSignal support to createAgentToolContext and MCP client loading - Add getCurrentTimeTool for time-aware AI responses - Add retry button to UserMessage component - Increase agent tool loop max steps from 5 to 50 Client: - Fix i18n: translate document titles and nav labels in settings pages and PageList Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
🤖 Augment PR SummarySummary: This PR expands Huntly’s MCP surface area across server + extension, adding date-range search/pagination support, abortable agent tool loading, and i18n fixes for document titles. Changes:
Technical Notes: Date filtering is applied in Lucene as a 🤖 Was this summary useful? React with 👍 or 👎 |
| String endDate = mcpUtils.getStringArg(arguments, "end_date"); | ||
| String dateField = mcpUtils.getStringArg(arguments, "date_field"); | ||
| int limit = Math.min(Math.max(mcpUtils.getIntArg(arguments, "limit", 50), 1), 500); | ||
| int page = Math.max(mcpUtils.getIntArg(arguments, "page", 1), 1); |
There was a problem hiding this comment.
app/server/huntly-server/src/main/java/com/huntly/server/mcp/tool/SearchContentTool.java:118 — page is only clamped to >=1, so a very large page combined with a large limit can drive page * size extremely high in Lucene (TopScoreDocCollector.create(page * size, ...)), risking integer overflow or excessive memory usage. This is user-controllable via the MCP tool arguments, so it can become a stability issue.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| if (date.contains("T") || date.contains(":")) { | ||
| return parseSearchDateTime(date); | ||
| } | ||
| return LocalDate.parse(date).atStartOfDay(ZoneId.systemDefault()).toInstant().plus(plusDay, ChronoUnit.DAYS); |
There was a problem hiding this comment.
app/server/huntly-server/src/main/java/com/huntly/server/service/LuceneService.java:704 — LocalDate.parse(...) (and LocalDateTime.parse(...) in the fallback path) can throw DateTimeParseException, which will bubble up and fail the whole search_content call for a simple typo in start_date/end_date. It may be worth ensuring invalid date inputs produce a controlled/agent-friendly error rather than an internal exception.
Severity: medium
Other Locations
app/server/huntly-server/src/main/java/com/huntly/server/service/LuceneService.java:714
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| Instant start = parseSearchDate(searchQuery.getStartDate(), 0); | ||
| Instant end = parseSearchDate(searchQuery.getEndDate(), 1); | ||
| long startEpochSecond = start != null ? start.getEpochSecond() : Long.MIN_VALUE; | ||
| long endEpochSecond = end != null ? end.getEpochSecond() - 1 : Long.MAX_VALUE; |
There was a problem hiding this comment.
app/server/huntly-server/src/main/java/com/huntly/server/service/LuceneService.java:670 — Subtracting 1 second from endEpochSecond makes end_date effectively exclusive at second granularity, which can be surprising when callers provide a precise timestamp (e.g., results at exactly the end second will be omitted). If this is intentional, it may need to be documented explicitly for date-time inputs (not just date-only inputs).
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
- Use <= threshold in isScrollPinnedToBottom and raise threshold to 160px - Switch useScrollPinToBottom to useLayoutEffect and direct scrollTop assignment to avoid rAF/scrollIntoView jitter during streaming - Cap SearchContentTool page to MAX_LUCENE_RESULT_WINDOW/MAX_LIMIT (20) to keep Lucene collection bounded; reflect constraint in schema and execute clamping - Add comprehensive hook integration tests and page-clamping unit test Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary
start_date/end_date/date_fielddate-range filtering and pagination (pageparameter) toSearchContentTool; exposecollectionId/collectedAtin allMcpPageItembuilder paths; add structured filter fields (contentType,libraryFilter,alreadyRead,searchTitleOnly) directly toSearchQueryinstead of relying on the legacyqueryOptionsstring; refactorMcpServerControllertool dispatch withgetToolArguments/executeToolhelpers; refactorLuceneServicesearch-option resolution and addbuildSearchDateRangeQueryListCollections,ListCollectionContent,GetXSaveRulesAbortSignalsupport tocreateAgentToolContextand MCP client loading so in-flight requests are cancelled when the user stops a chat; addgetCurrentTimeToolfor time-aware AI responses; add retry button (RotateCcw) toUserMessage; increase agent tool loop max steps from 5 → 50PageListso they update correctly on language switchTest plan
./mvnw testinhuntly-server— new unit tests inSearchContentToolTest,CollectionMcpToolsTest,GetXSaveRulesToolTest,McpUtilsTest,LuceneServiceSearchSyntaxTest,McpServerControllerTestall passyarn testinapp/extension—agentToolsAbort.test.tsandUserMessage.test.tsxpassstart_date/end_datereturns only items in range🤖 Generated with Claude Code