feat: add archiveInterval, archiveGracePeriod, and archiveMaxObjectBytes audit log archival config options - #5229
Merged
Pratham-Mishra04 merged 1 commit intoJul 17, 2026
Conversation
Contributor
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 24 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds audit-log archival tuning fields for interval, grace period, and maximum object size across transport and Helm schemas, wires optional Helm values into generated configuration, and updates object-storage archival documentation to describe windowed JSONL parts and manifests. ChangesAudit archival configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
Author
impoiler
changed the title
archiveInterval, archiveGracePeriod, and archiveMaxObjectBytes audit log archival config options
impoiler
marked this pull request as ready for review
July 15, 2026 06:33
Contributor
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (4): Last reviewed commit: "feat: allow time interval and size flexi..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@transports/config.schema.json`:
- Around line 5789-5799: Update the duration regex patterns for archive_interval
and archive_grace_period in transports/config.schema.json at lines 5789-5799 to
accept both “us” and “µs” units. Apply the same pattern changes to the
corresponding fields in helm-charts/bifrost/values.schema.json at lines
3519-3529, preserving all existing duration formats.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 601b21d7-692b-4529-81e5-26ee208c5a25
📒 Files selected for processing (4)
helm-charts/bifrost/templates/_helpers.tplhelm-charts/bifrost/values.schema.jsonhelm-charts/bifrost/values.yamltransports/config.schema.json
impoiler
force-pushed
the
07-15-feat_allow_time_interval_and_size_flexibility_in_audit_logs_in_object_storage
branch
from
July 15, 2026 08:34
d6008e8 to
78dadcf
Compare
This was referenced Jul 15, 2026
impoiler
force-pushed
the
07-15-feat_allow_time_interval_and_size_flexibility_in_audit_logs_in_object_storage
branch
from
July 16, 2026 06:08
78dadcf to
c0ea503
Compare
impoiler
force-pushed
the
graphite-base/5229
branch
from
July 16, 2026 06:08
c0909f9 to
b3b430c
Compare
impoiler
changed the base branch from
graphite-base/5229
to
07-15-fix_tool_sync_interval_bug_fix_backend
July 16, 2026 06:08
This was referenced Jul 16, 2026
impoiler
force-pushed
the
07-15-fix_tool_sync_interval_bug_fix_backend
branch
from
July 16, 2026 06:09
b3b430c to
c326247
Compare
impoiler
force-pushed
the
07-15-feat_allow_time_interval_and_size_flexibility_in_audit_logs_in_object_storage
branch
from
July 16, 2026 06:09
c0ea503 to
a6e8d94
Compare
This was referenced Jul 16, 2026
Collaborator
Merge activity
|
Pratham-Mishra04
changed the base branch from
07-15-fix_tool_sync_interval_bug_fix_backend
to
graphite-base/5229
July 17, 2026 11:36
Pratham-Mishra04
dismissed
coderabbitai[bot]’s stale review
July 17, 2026 11:40
The base branch was changed.
Pratham-Mishra04
force-pushed
the
07-15-feat_allow_time_interval_and_size_flexibility_in_audit_logs_in_object_storage
branch
from
July 17, 2026 11:40
a6e8d94 to
6b4a3f9
Compare
Pratham-Mishra04
deleted the
07-15-feat_allow_time_interval_and_size_flexibility_in_audit_logs_in_object_storage
branch
July 17, 2026 11:42
akshaydeo
pushed a commit
that referenced
this pull request
Jul 17, 2026
…ectBytes` audit log archival config options (#5229) ## Summary Adds three new tunable parameters for audit log archival to object storage: `archive_interval`, `archive_grace_period`, and `archive_max_object_bytes`. These allow operators to control the archival window size, how long a window stays open past its end to absorb late inserts, and the maximum uncompressed size of each part object before rolling to a new one. ## Changes - Added `archive_interval` (default `24h`, minimum `5m`) to control the archival window size and background job period. Each closed window is written as a set of objects to object storage. - Added `archive_grace_period` (default `15m`) to hold a window open past its end before archiving, absorbing clock skew and late inserts. Must be less than `archive_interval`. - Added `archive_max_object_bytes` (default `128MiB`, range `1MiB–4GiB`) to roll a new part object once the current part reaches the specified uncompressed byte threshold. Peak memory on the archiving node is roughly 2x this value when compression is enabled. - Updated the object storage description to reflect the new windowed archival model: a background job writes each closed window as one or more JSONL part objects plus a manifest at `{prefix}/audit-logs/YYYY/MM/DD/{start}-{end}/`. The manifest is the authoritative index for a window; any object not listed in it should be ignored. - Updated `values.yaml` comments to document the new parameters and clarify archival behavior (no backfill, no row deletion, leader-only in a cluster). ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [x] Core (Go) - [x] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test Deploy bifrost with `objectStorage` configured and set non-default values for the new parameters: ```yaml bifrost: auditLogs: archiveInterval: "1h" archiveGracePeriod: "5m" archiveMaxObjectBytes: 10485760 # 10MiB objectStorage: type: s3 bucket: my-bucket ``` Verify that: - Audit events are archived into windowed paths (`YYYY/MM/DD/{start}-{end}/part-00000.jsonl[.gz]`) rather than the old per-batch path. - A `manifest.json[.gz]` is written alongside each set of part objects. - Windows only close after `archiveGracePeriod` has elapsed past the window end. - Part objects roll over once they reach `archiveMaxObjectBytes` uncompressed bytes. ```sh go test ./... ``` **New config parameters:** | Parameter | Default | Description | |---|---|---| | `archive_interval` / `archiveInterval` | `24h` | Archival window size and job period (minimum `5m`) | | `archive_grace_period` / `archiveGracePeriod` | `15m` | Grace period past window end before archiving; must be less than `archive_interval` | | `archive_max_object_bytes` / `archiveMaxObjectBytes` | `134217728` (128MiB) | Max uncompressed bytes per part object before rolling; clamped to `[1MiB, 4GiB]` | ## Breaking changes - [ ] Yes - [x] No ## Security considerations `archive_max_object_bytes` directly influences peak memory consumption on the archiving node (roughly 2x the value when compression is enabled). Operators should size pod memory limits accordingly to avoid OOM conditions when tuning this value upward. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [ ] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
akshaydeo
pushed a commit
that referenced
this pull request
Jul 18, 2026
…ectBytes` audit log archival config options (#5229) ## Summary Adds three new tunable parameters for audit log archival to object storage: `archive_interval`, `archive_grace_period`, and `archive_max_object_bytes`. These allow operators to control the archival window size, how long a window stays open past its end to absorb late inserts, and the maximum uncompressed size of each part object before rolling to a new one. ## Changes - Added `archive_interval` (default `24h`, minimum `5m`) to control the archival window size and background job period. Each closed window is written as a set of objects to object storage. - Added `archive_grace_period` (default `15m`) to hold a window open past its end before archiving, absorbing clock skew and late inserts. Must be less than `archive_interval`. - Added `archive_max_object_bytes` (default `128MiB`, range `1MiB–4GiB`) to roll a new part object once the current part reaches the specified uncompressed byte threshold. Peak memory on the archiving node is roughly 2x this value when compression is enabled. - Updated the object storage description to reflect the new windowed archival model: a background job writes each closed window as one or more JSONL part objects plus a manifest at `{prefix}/audit-logs/YYYY/MM/DD/{start}-{end}/`. The manifest is the authoritative index for a window; any object not listed in it should be ignored. - Updated `values.yaml` comments to document the new parameters and clarify archival behavior (no backfill, no row deletion, leader-only in a cluster). ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [x] Core (Go) - [x] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test Deploy bifrost with `objectStorage` configured and set non-default values for the new parameters: ```yaml bifrost: auditLogs: archiveInterval: "1h" archiveGracePeriod: "5m" archiveMaxObjectBytes: 10485760 # 10MiB objectStorage: type: s3 bucket: my-bucket ``` Verify that: - Audit events are archived into windowed paths (`YYYY/MM/DD/{start}-{end}/part-00000.jsonl[.gz]`) rather than the old per-batch path. - A `manifest.json[.gz]` is written alongside each set of part objects. - Windows only close after `archiveGracePeriod` has elapsed past the window end. - Part objects roll over once they reach `archiveMaxObjectBytes` uncompressed bytes. ```sh go test ./... ``` **New config parameters:** | Parameter | Default | Description | |---|---|---| | `archive_interval` / `archiveInterval` | `24h` | Archival window size and job period (minimum `5m`) | | `archive_grace_period` / `archiveGracePeriod` | `15m` | Grace period past window end before archiving; must be less than `archive_interval` | | `archive_max_object_bytes` / `archiveMaxObjectBytes` | `134217728` (128MiB) | Max uncompressed bytes per part object before rolling; clamped to `[1MiB, 4GiB]` | ## Breaking changes - [ ] Yes - [x] No ## Security considerations `archive_max_object_bytes` directly influences peak memory consumption on the archiving node (roughly 2x the value when compression is enabled). Operators should size pod memory limits accordingly to avoid OOM conditions when tuning this value upward. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [ ] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Adds three new tunable parameters for audit log archival to object storage:
archive_interval,archive_grace_period, andarchive_max_object_bytes. These allow operators to control the archival window size, how long a window stays open past its end to absorb late inserts, and the maximum uncompressed size of each part object before rolling to a new one.Changes
archive_interval(default24h, minimum5m) to control the archival window size and background job period. Each closed window is written as a set of objects to object storage.archive_grace_period(default15m) to hold a window open past its end before archiving, absorbing clock skew and late inserts. Must be less thanarchive_interval.archive_max_object_bytes(default128MiB, range1MiB–4GiB) to roll a new part object once the current part reaches the specified uncompressed byte threshold. Peak memory on the archiving node is roughly 2x this value when compression is enabled.{prefix}/audit-logs/YYYY/MM/DD/{start}-{end}/. The manifest is the authoritative index for a window; any object not listed in it should be ignored.values.yamlcomments to document the new parameters and clarify archival behavior (no backfill, no row deletion, leader-only in a cluster).Type of change
Affected areas
How to test
Deploy bifrost with
objectStorageconfigured and set non-default values for the new parameters:Verify that:
YYYY/MM/DD/{start}-{end}/part-00000.jsonl[.gz]) rather than the old per-batch path.manifest.json[.gz]is written alongside each set of part objects.archiveGracePeriodhas elapsed past the window end.archiveMaxObjectBytesuncompressed bytes.go test ./...New config parameters:
archive_interval/archiveInterval24h5m)archive_grace_period/archiveGracePeriod15marchive_intervalarchive_max_object_bytes/archiveMaxObjectBytes134217728(128MiB)[1MiB, 4GiB]Breaking changes
Security considerations
archive_max_object_bytesdirectly influences peak memory consumption on the archiving node (roughly 2x the value when compression is enabled). Operators should size pod memory limits accordingly to avoid OOM conditions when tuning this value upward.Checklist
docs/contributing/README.mdand followed the guidelines