fix(secrets): Remove incorrect JSON escaping in updateSecret that corrupts special characters

[acrylJonny]

The escaping was unnecessary because GraphQL already handles proper deserialization of the input value. Adding JSON escaping at this stage doubles-escapes the value, corrupting it.

Solution

• Removed the StringEscapeUtils.escapeJson() call from UpdateSecretResolver
• Removed the unused import org.apache.commons.text.StringEscapeUtils
• Both createSecret and updateSecret now use the same approach: directly encrypt the input value

Testing

• Verified that secrets with newlines, forward slashes, and other special characters can now be updated without corruption
• Confirmed consistency between create and update operations

Impact

• Secrets with special characters can now be updated correctly
• Existing corrupted secrets will need to be updated again to fix their values

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[sgomezvillamor]

While this looks to me, it concerns me that the escaping was added about 3 months ago in PR #14578

In order to unblock and clarify, what about adding a proper smoke test that:

• adds a fake bigquery credential private key as secret and
• reads ok
• updates it
• reads ok

WDYT?

[acrylJonny]

While this looks to me, it concerns me that the escaping was added about 3 months ago in PR #14578

In order to unblock and clarify, what about adding a proper smoke test that:

• adds a fake bigquery credential private key as secret and
• reads ok
• updates it
• reads ok

WDYT?

Yeah, I think that makes sense. It seems strange that the previous change was made only for updates. Let me see if there's something I can alter to still cater for the special characters like doubly/single quotes but I'll apply it across the create and update commands.

But yeah, I think your proposal of that smoke test makes sense. I'll look to add that.

[acrylJonny]

While this looks to me, it concerns me that the escaping was added about 3 months ago in PR #14578
In order to unblock and clarify, what about adding a proper smoke test that:

• adds a fake bigquery credential private key as secret and
• reads ok
• updates it
• reads ok

WDYT?

Yeah, I think that makes sense. It seems strange that the previous change was made only for updates. Let me see if there's something I can alter to still cater for the special characters like doubly/single quotes but I'll apply it across the create and update commands.

But yeah, I think your proposal of that smoke test makes sense. I'll look to add that.

@sgomezvillamor - smoke test has now been added