vault: backport instrumentation and observation blob parallelization to 2.40.0#21761
vault: backport instrumentation and observation blob parallelization to 2.40.0#21761prashantkumar1982 wants to merge 16 commits intorelease/2.40.0from
Conversation
Instrument all public KVStore methods with a histogram metric (platform_vault_plugin_kv_operation_duration_seconds) to help diagnose high P95 Observation latencies in production. Also adds a max-batch Observation test exercising 10 GetSecrets requests with 10 encryption keys each plus 20 pending queue items.
|
✅ No conflicts with other open PRs targeting |
|
I see you updated files related to
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 61526464b2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| batchSize.DefaultValue = int(configProto.BatchSize) | ||
| } | ||
| cfg.MaxBatchSize, err = limits.MakeUpperBoundLimiter(r.limitsFactory, batchSize) | ||
| cfg.MaxBatchSize, err = limits.MakeUpperBoundLimiter(r.limitsFactory, cresettings.Default.VaultPluginBatchSizeLimit) |
There was a problem hiding this comment.
Preserve offchain BatchSize override when creating limiter
NewReportingPlugin now always builds cfg.MaxBatchSize from cresettings.Default.VaultPluginBatchSizeLimit, even though it has already unmarshaled configProto and still honors other per-plugin overrides (like MaxSecretsPerOwner). This silently ignores ReportingPluginConfig.BatchSize, so deployments that set a non-default batch size will run with the default limit and can unexpectedly truncate pending queue observations (2*MaxBatchSize) or diverge from intended configuration.
Useful? React with 👍 / 👎.
Pull Request is not mergeable
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 54be050ca4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| batchSize.DefaultValue = int(configProto.BatchSize) | ||
| } | ||
| cfg.MaxBatchSize, err = limits.MakeUpperBoundLimiter(r.limitsFactory, batchSize) | ||
| cfg.MaxBatchSize, err = limits.MakeUpperBoundLimiter(r.limitsFactory, cresettings.Default.VaultPluginBatchSizeLimit) |
There was a problem hiding this comment.
Honor BatchSize from offchain config in limiter setup
NewReportingPlugin now always builds cfg.MaxBatchSize from cresettings.Default.VaultPluginBatchSizeLimit, so ReportingPluginConfig.BatchSize is ignored even when it is explicitly set in offchain config. This changes runtime behavior for deployed jobs that rely on non-default batch sizing, and can cause unexpected truncation/rejection paths tied to MaxBatchSize (for example, pending-queue observation limits at 2*MaxBatchSize).
Useful? React with 👍 / 👎.
|




Summary
This backports the Vault instrumentation and Observation blob broadcast parallelization changes to
release/2.40.0.What changed
Observation()Testing