feat(policy): add MemoryGetObjectBioAction - #256
Conversation
|
Warning Review limit reached
Next review available in: 57 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR adds ChangesMemory action support
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@policy/memory-action_test.go`:
- Line 42: Extend the focused tests in memory-action_test.go to cover
createMemoryActionConditionKeyMap, verifying that a valid memory action includes
the common condition keys while excluding MemoryPrefix and MemoryMaxKeys. Keep
the existing IsValid test, and assert the non-enumeration contract explicitly
using the definitions in memory-action.go.
In `@policy/memory-action.go`:
- Around line 68-69: Update the GoDoc for MemoryGetObjectBioAction to state that
it targets a single object and therefore does not use enumeration condition
keys, while retaining the existing description of its version history and
provenance behavior.
🪄 Autofix
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: ASSERTIVE
Plan: Pro Plus
Run ID: 36d765ac-d816-4e72-b158-9803207073d3
📒 Files selected for processing (2)
policy/memory-action.gopolicy/memory-action_test.go
| {MemoryDeleteAgentAction, true}, | ||
| {MemoryListAgentsAction, true}, | ||
| {MemorySearchAction, true}, | ||
| {MemoryGetObjectBioAction, true}, |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win
Cover the condition-key contract, not only action validity.
This case proves that MemoryGetObjectBioAction.IsValid() returns true. It does not verify that the action receives common condition keys but excludes MemoryPrefix and MemoryMaxKeys. Add or extend a focused test for createMemoryActionConditionKeyMap.
Based on the action-condition-key contract in policy/memory-action.go, test the non-enumeration behavior explicitly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@policy/memory-action_test.go` at line 42, Extend the focused tests in
memory-action_test.go to cover createMemoryActionConditionKeyMap, verifying that
a valid memory action includes the common condition keys while excluding
MemoryPrefix and MemoryMaxKeys. Keep the existing IsValid test, and assert the
non-enumeration contract explicitly using the definitions in memory-action.go.
| // MemoryGetObjectBioAction - read one object's version history and | ||
| // per-version provenance from a cortex. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Document the non-enumeration rationale in the GoDoc comment.
The current comment describes what the action returns. Repository guidance requires comments to explain why the code exists. State that this action targets one object and therefore does not use enumeration condition keys.
Proposed comment
- // MemoryGetObjectBioAction - read one object's version history and
- // per-version provenance from a cortex.
+ // MemoryGetObjectBioAction targets one object's history instead of
+ // enumerating records, so enumeration condition keys do not apply.As per coding guidelines, keep comments minimal and explain why the code exists.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // MemoryGetObjectBioAction - read one object's version history and | |
| // per-version provenance from a cortex. | |
| // MemoryGetObjectBioAction targets one object's history instead of | |
| // enumerating records, so enumeration condition keys do not apply. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@policy/memory-action.go` around lines 68 - 69, Update the GoDoc for
MemoryGetObjectBioAction to state that it targets a single object and therefore
does not use enumeration condition keys, while retaining the existing
description of its version history and provenance behavior.
Source: Coding guidelines
An object's biography is who authored each version of it, when, from which agent and session, and what that version carries. Reading it is a different question from reading the object, which returns bytes and says nothing about who put them there, so it needs an action of its own. Registered as a read: it names one record in its resource and has no query to constrain, so the enumeration condition keys do not apply.
d7a15e3 to
1dacab2
Compare
|
Closing in favour of #255, which Dil opened first and which carries the same change. I pushed the doc-comment wording onto that branch instead — an object biography is who authored each version, when, from which agent and session, not a version history. |
1 participant
Description
Adds
memory:GetObjectBioto the Memory API action set.Motivation
AIStor's Memory API is growing an object-bio route that returns one object's
version history and per-version provenance. Every other Memory surface
authorizes a
memory:*action viaauthorizeMemoryAction; without thisconstant the route has to borrow an S3 action, which grants the caller more
than the route needs and makes it the one inconsistent member of the family.
Registered as a read rather than an enumeration: it names one record in its
resource and has no query to constrain, so
MemoryPrefix/MemoryMaxKeysdonot apply.
How to test
go test ./policy/ -run Memory—TestMemoryActionIsValidcovers the newconstant.
Summary by CodeRabbit
memory:GetObjectBioaction.