feat: Phase 4+6 — patterns pagination, confidence fix, HEARTBEAT filter#29
Conversation
T039: HEARTBEAT prompts (workspace health checks) now exit early before triggering context search, tier classification, or tracking. Prevents unnecessary noise in activity timeline and search analytics.
… fix
T018: Patterns page overhaul:
- Backend: GetActivePatterns now accepts limit, offset, sort params
- Backend: Added CountActivePatterns for total count
- Backend: DefaultPatternsLimit raised to 500
- Backend: handleGetPatterns returns {patterns, total} with DB-level sorting
- Frontend: Server-side pagination replaces client-side slicing
- Frontend: Sort triggers server fetch instead of local sort
- Confidence formula: ceiling raised from 0.9 to 1.0 (freqConfidence weight 0.4→0.5)
- All callers of GetActivePatterns updated to new signature
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughВнедрена серверная пагинация и сортировка для списка шаблонов: Changes
Sequence Diagram(s)sequenceDiagram
participant UI as Browser/UI
participant API as Server (handlers_patterns)
participant Store as PatternStore
participant DB as Database
UI->>API: GET /patterns?limit=..&offset=..&sort=..
activate API
API->>Store: CountActivePatterns(ctx) note right of Store: unfiltered path
Store->>DB: SELECT COUNT(*) FROM patterns WHERE status='active'
DB-->>Store: total
Store-->>API: total
API->>Store: GetActivePatterns(ctx, limit, offset, sort)
Store->>DB: SELECT ... ORDER BY <sort> LIMIT <limit> OFFSET <offset>
DB-->>Store: patterns[]
Store-->>API: patterns[]
API-->>UI: { patterns: [...], total: N }
deactivate API
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Стих
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
📝 Coding Plan
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.11.3)Error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions Comment |
Summary of ChangesHello, 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 significantly enhances the "Patterns" feature by migrating its data retrieval to a server-side pagination and sorting model, improving performance and scalability for larger datasets. It also refines the pattern confidence calculation to allow for higher accuracy scores and introduces a filter to exclude internal system health checks (HEARTBEAT prompts) from user-facing pattern processing, ensuring a cleaner and more relevant user experience. 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. Footnotes
|
|
@coderabbitai review |
|
@gemini-code-assist review |
✅ Actions performedReview triggered.
|
|
@codex review |
![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 server-side pagination for the Patterns page, which is a great improvement for performance. The backend is updated to handle limit, offset, and sorting at the database level, and the frontend is refactored to use this new API. The changes are well-implemented, but I've found a bug in the backend where the total count for filtered pattern lists is calculated incorrectly, which will break pagination for those views. I've also identified a potential UI inconsistency on the frontend where deleting or deprecating a pattern updates the local state instead of refetching from the server, which can lead to a stale view with server-side pagination.
There was a problem hiding this comment.
Code Review
This pull request introduces server-side pagination for the Patterns page, which is a great improvement for performance and scalability. The backend changes in Go correctly add limit, offset, and sorting capabilities to the GetActivePatterns function. The frontend is also updated accordingly to use these new parameters.
My review has identified a few issues:
- A high-severity bug in the backend handler where the total pattern count is calculated incorrectly for filtered views, which will break pagination for those cases.
- A medium-severity issue on the frontend where local state for the total count is manipulated, which could lead to inconsistencies.
- A medium-severity bug in the Vue component that can cause redundant API calls when changing sort or page size options.
I've provided detailed comments and suggestions for fixing these issues. Overall, this is a solid implementation of a key feature, and with these fixes, it will be much more robust.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (1)
internal/db/gorm/pattern_store_test.go (1)
202-202: Стоит добавить тесты для новых веток пагинации и сортировки.Сейчас проверяется только дефолтный путь. Рекомендую дополнить кейсами для
sort=confidence,sort=last_seen,offset>0и отдельным тестом дляCountActivePatterns, чтобы зафиксировать новое поведение API.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/db/gorm/pattern_store_test.go` at line 202, Add test cases in pattern_store_test.go exercising the alternative pagination and sorting branches: call patternStore.GetActivePatterns(ctx, limit, offset, "confidence") and with "last_seen" to assert ordering, and call with offset>0 to verify pagination skips correctly; also add a separate test for patternStore.CountActivePatterns(ctx) to assert total counts match expected after inserts. Locate tests around existing GetActivePatterns usage to mirror setup/teardown, create deterministic sample patterns with varying confidence and last_seen values, and assert both the returned slice order/length and CountActivePatterns results to lock in the new API behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal/db/gorm/pattern_store.go`:
- Around line 151-157: The current ORDER BY built in pattern_store.go (the
orderClause variable and the switch on sort) is not deterministic when
frequency/confidence/last_seen_at_epoch tie, causing pagination
duplicates/misses; update the orderClause construction inside the switch (and
the default) to append a stable tiebreaker such as the primary key column (e.g.,
"id" or "pattern_id") or created_at to ensure deterministic ordering across
pages (e.g., "... , frequency DESC, confidence DESC, id DESC"); modify the
branches for "confidence" and "last_seen" similarly so every ordering path
includes the same unique deterministic tie-breaker.
In `@internal/worker/handlers_patterns.go`:
- Around line 70-77: Ветка фильтрации по type/project нарушает контракт
пагинации: offset и sort игнорируются и total берётся как len(patterns). Fix:
when patternType != "" call a CountPatternsByType(ctx,
models.PatternType(patternType)) to set total and then call
GetPatternsByType(ctx, models.PatternType(patternType), limit, offset, sort) (or
the store equivalents that accept offset/sort); similarly for project use
CountPatternsByProject and GetPatternsByProject with limit/offset/sort.
Альтернативно, если бекенд не поддерживает комбинацию фильтра+пагинации — явно
возвращать 400 error when offset/sort provided with patternType/project and
document that limitation.
In `@plugin/openclaw-engram/src/hooks/before-prompt-build.ts`:
- Around line 45-47: The early-return check in the before-prompt-build hook uses
promptLower.includes(...) which erroneously matches any prompt containing those
substrings; change it to exact-match logic (e.g., normalize promptLower with
trim() and test equality against 'heartbeat.md' and 'heartbeat_ok' or use a
strict regex like /^(heartbeat\.md|heartbeat_ok)$/i) so only exact health-check
signatures in the prompt variable (promptLower) trigger the return; update the
conditional around promptLower in the before-prompt-build handler accordingly.
In `@ui/src/composables/usePatterns.ts`:
- Around line 54-55: The code always decrements total.value after filtering
patterns.value, which can desynchronize the counter when the id wasn't present;
update the remove logic in the function that filters by id (references:
patterns.value, total.value, id) to only decrement total.value when an actual
removal occurred — e.g., capture the previous length or check if the item
existed (findIndex/includes) before filtering and decrement total.value (with
Math.max(0, ...)) only if an item was removed; apply the same fix to the
analogous block around the references at the other location (lines 65-66).
In `@ui/src/views/PatternsView.vue`:
- Around line 49-54: The client-side filter in visiblePatterns (which filters
patterns.value by searchQuery) only affects the current page while the
Pagination and total counter still reflect the full dataset, causing
inconsistent UX; fix by either (preferred) moving the search into loadPatterns
so the server accepts a search query parameter and returns paginated results
plus a totalCount used by Pagination, or (alternative) make the UI explicit that
the name filter is page-scoped by removing the global counter and updating
Pagination/labels and the computed visiblePatterns to clearly state "filtering
current page only"; update references to visiblePatterns, patterns, searchQuery,
loadPatterns, and Pagination accordingly so the total shown and pages reflect
server-filtered results (or the UI text/counter reflects a page-limited filter).
- Around line 62-69: When watching [sortBy, itemsPerPage] (the watcher using
sortBy, itemsPerPage, currentOffset, fetchCurrentPage), avoid forcing a
duplicate fetch by only resetting currentOffset.value to 0 when it actually
differs from 0; implement: if currentOffset.value !== 0 then set
currentOffset.value = 0 (do not call fetchCurrentPage there because the
currentOffset watcher will run), otherwise call fetchCurrentPage() directly—this
ensures fetchCurrentPage() is invoked exactly once when sort or page size
changes.
---
Nitpick comments:
In `@internal/db/gorm/pattern_store_test.go`:
- Line 202: Add test cases in pattern_store_test.go exercising the alternative
pagination and sorting branches: call patternStore.GetActivePatterns(ctx, limit,
offset, "confidence") and with "last_seen" to assert ordering, and call with
offset>0 to verify pagination skips correctly; also add a separate test for
patternStore.CountActivePatterns(ctx) to assert total counts match expected
after inserts. Locate tests around existing GetActivePatterns usage to mirror
setup/teardown, create deterministic sample patterns with varying confidence and
last_seen values, and assert both the returned slice order/length and
CountActivePatterns results to lock in the new API behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: faa8329d-f364-4474-b501-b4cb0fec6366
📒 Files selected for processing (11)
internal/db/gorm/pattern_store.gointernal/db/gorm/pattern_store_test.gointernal/mcp/server.gointernal/pattern/decay.gointernal/worker/handlers_maintenance.gointernal/worker/handlers_patterns.gopkg/models/pattern.goplugin/openclaw-engram/src/hooks/before-prompt-build.tsui/src/composables/usePatterns.tsui/src/utils/api.tsui/src/views/PatternsView.vue
- Add id DESC tiebreaker to all ORDER BY clauses in GetActivePatterns - Guard type/project filter total count against err before assignment - Document that type/project filters don't support offset pagination
🤖 PR Review MCP State (auto-managed, do not edit){
"version": 2,
"parentChildren": {},
"resolvedNitpicks": {
"coderabbit-nitpick-117c249c-202": {
"resolvedAt": "2026-03-20T12:58:26.095Z",
"resolvedBy": "agent"
}
},
"updatedAt": "2026-03-20T12:58:26.653Z"
} |
1 participant
Summary
Changes
Backend (Go)
pattern_store.go:GetActivePatterns(ctx, limit, offset, sort)— DB-level pagination+sortingpattern_store.go: NewCountActivePatterns(ctx)for total counthandlers_patterns.go: Returns{patterns, total}, acceptslimit/offset/sortparams, DefaultPatternsLimit 100→500pattern.go: Confidence formula weight 0.4→0.5, ceiling 0.9→1.0Frontend (Vue/TS)
PatternsView.vue: Server-side pagination replaces client-side slicingusePatterns.ts: Passes limit/offset/sort params, exposestotalrefapi.ts:fetchPatternsreturnsPatternsResponse {patterns, total}Plugin (TypeScript)
before-prompt-build.ts: Skip HEARTBEAT prompts (workspace health checks)Test plan
Summary by CodeRabbit
Примечания к выпуску