[
https://issues.apache.org/jira/browse/CAMEL-23707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-23707:
--------------------------------
Priority: Minor (was: Major)
> `camel get vault` reports wrong vault type when multiple vault providers are
> configured with a single secret each
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-23707
> URL: https://issues.apache.org/jira/browse/CAMEL-23707
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
> Affects Versions: 4.20.0
> Reporter: Adriano Machado
> Assignee: Adriano Machado
> Priority: Minor
>
> h2. Summary
> {{ListVault.doProcessWatchCall()}} reuses the same {{Row}} object across
> vault-type processing blocks. The {{row.copy()}} call that isolates each row
> is guarded by {{i > 0}}, which means it only fires for the 2nd and subsequent
> secrets within a single vault. When a vault has exactly one secret, the row
> is added to the list while {{row}} still points to the same object. Every
> subsequent vault block then mutates that already-added object through
> {{row.vault = "GCP"}}, {{row.vault = "Azure"}}, etc., so all rendered rows
> end up carrying the label of the last vault type processed.
> h2. Steps to Reproduce
> Configure a Camel integration with two or more vault providers (e.g., AWS
> Secrets Manager + GCP Secret Manager), each referencing a single secret. Run:
> {code}
> camel get vault
> {code}
> h2. Expected Result
> Each row shows its own vault type (AWS, GCP, ...).
> h2. Actual Result
> Every row shows the vault type of the last provider processed (e.g., all rows
> show "Azure" when AWS + GCP + Azure are all active).
> The same corruption is present in {{--output json}} mode, because the bug
> occurs during row collection, before the {{jsonOutput}} branch is reached.
> h2. Affected Code
> {{dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/process/ListVault.java}},
> method {{doProcessWatchCall()}}. The pattern repeats for every vault type
> block (AWS, GCP, Azure, Kubernetes, Kubernetes configmaps).
> h2. Fix Direction
> Before the first secret loop in each vault block, unconditionally reset
> {{row}} to a fresh copy so it is no longer aliased to any already-added
> entry. The {{i > 0}} guard can then be removed or left in place, because
> {{row}} will already be an isolated object at loop entry.
> h2. Regression Tests
> Two {{@Disabled}} JUnit 5 tests documenting the failure are in
> {{ListVaultTest}} (table output and JSON output variants). They can be
> re-enabled to verify the fix.
> _Claude Code on behalf of Adriano Machado_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
