Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature]: hermes-plugin — forward events_time_decay_protection on auto-recall (parity with #6390)

Open Beginner friendly
  • Is something wrong?
#6,533 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@dajiaohuang is already working on this.

Since Oct 25, 2026.

  • #6574 by @dajiaohuang — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
80/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python, yaml
Domain
search

Research direction

Start in examples/hermes-plugin/__init__.py where the auto-recall request body is built alongside scope/limit/score_threshold. Add a recall_events_time_decay_protection config field and forward it in the POST /api/v1/search/find call. Done when the plugin sends the field and matches #6390 parity; verify by inspecting the outgoing request in a local run.

Written by the indexing model from the issue text.

Description

Issue Origin

Observed or reproduced in a real environment.

Thanks for OpenViking — #6389 / #6390 already established the right pattern (forward an event time-decay window from recall config). This asks for the same parity on the Python hermes-plugin, which that PR did not touch.

Problem Statement

The server accepts events_time_decay_protection on search/find / search (event memories keep their score inside the protection window and decay after it — utils/time_decay.py, EVENT_TIME_DECAY_SCALE = "7d", EVENT_TIME_DECAY_DECAY = 0.5). The Hermes plugin never sends it: 0 occurrences in examples/hermes-plugin/__init__.py on current main. So Hermes auto-recall always ranks events time-blind, and superseded events outrank terminal-state events on status questions — the exact failure class described in #6389, surviving on the Python plugin.

Observed in a live store (scenario details withheld; pattern: a "scheduled/confirmed" event stored earlier on some subject is later superseded by a newer terminal-state event on the same subject):

  • POST /api/v1/search/find as the owning tenant, target_uri=<user>/memories, status-style queries in Chinese (e.g. "…什么进展", "…结果如何"):
    • top-1 is the older "scheduled/confirmed" event (0.890); the newer terminal-state event sits at #3 (0.852).
    • on the rephrased status query, the newer event falls out of the top 6 entirely.
  • Consequence: the agent answering "what is the current status?" retrieves the superseded event first and confidently reports a pending state for a matter that closed days earlier. Re-ranking cannot fix this — the reranker measures semantic relevance, and the old event genuinely is relevant.

Illustrative shape: subject X — "demo with vendor scheduled" event on day D, "declined the offer" event on day D+3; the day-D event still wins every "what's the status of X" recall.

Proposed Solution

Mirror the #6390 config-forwarding pattern on the Python plugin:

  • Add a plugin config field recall_events_time_decay_protection (window string such as 7d; unset = today's behavior) alongside the existing recall_* fields (recall_limit, recall_score_threshold, …).
  • When set, include it in the auto-recall request body (the same call that already forwards scope / limit / score_threshold), and optionally on the viking_search tool's deep path.

Alternatives Considered

  • Server-side default protection — changes ranking for every existing caller at once; a per-deployment opt-in is safer.
  • Client-side recency re-sort in the plugin — unreliable: score-threshold trimming can drop the newest event before the client ever sees it (the newer event above never made top 6).
  • Time-range filters (#5443) — complementary, but recall does not know each entity's last-touched date, so it cannot pick the window per query.

Feature Area

Retrieval/Search (agent-plugins, examples/hermes-plugin)

Use Case

Family/personal agents whose memory tracks ongoing situations with changing terminal states (decisions in flight, bookings, applications of various kinds). Most auto-recall queries are "what is the current status?" — precisely the queries where a stale-but-relevant event must lose to a newer terminal-state event. Today every Hermes deployment runs with decay silently off.

Example API

# plugin.yaml
recall:
  events_time_decay_protection: "7d"   # unset = today's behavior

# forwarded on the recall context search
POST /api/v1/search/find
{"query": "...", "target_uri": "viking://user/<user>/memories",
 "limit": 6, "events_time_decay_protection": "7d"}

Additional Context

  • Observed on: OpenViking server v0.5.2 (docker, local index backend), Hermes Agent v0.22.4, hermes-plugin pinned at 9f150ece247ad683494ab172d738023bd6dc6170 (2026-10-08). Verified examples/hermes-plugin/__init__.py on main (as of e63eb0d8, 2026-10-22) still contains zero occurrences of the field.
  • The shared JS plugins (claude-code / codex / openclaw) already forward this via #6390; the Python hermes-plugin is the remaining outlier.

Contribution

  • I am willing to contribute to implementing this feature
Dominant language
Python
Stars
40.8k
Forks
3.3k
Avg merge
1d 5h
Merged PRs (30d)
408

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.