Explicitly flag config sensitivity

[johnnymugs]

Description

Explicitly flag configs as insensitive where appropriate. This is in preparation for configs to default to sensitive: true and explicitly opt in to revealing in logs etc.

In preparation for this change: smartcontractkit/ea-framework-js#660

Will update framework for all EAs in a follow up PR

......

Changes

• Explicitly flag configs as insensitive where appropriate

Steps to Test

1. Check logs & debug endpoint, appropriate configs should still be visible

Quality Assurance

• If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant infra-k8s configuration file.
• If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant adapter-secrets configuration file.
• If a new adapter was made, or a new endpoint was added, update the test-payload.json file with relevant requests.
• The branch naming follows git flow (feature/x, chore/x, release/x, hotfix/x, fix/x) or is created from Jira.
• This is related to a maximum of one Jira story or GitHub issue.
• Types are safe (avoid TypeScript/TSLint features like any and disable, instead use more specific types).
• All code changes have 100% unit and integration test coverage. If testing is not applicable or too difficult to justify doing, the reasoning should be documented explicitly in the PR.

[changeset-bot]

🦋 Changeset detected

Latest commit: 281211d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 38 packages

Name	Type
@chainlink/solana-functions-adapter	Patch
@chainlink/tokenized-equity-adapter	Patch
@chainlink/fireblocks-adapter	Patch
@chainlink/coinmetrics-lwba-adapter	Patch
@chainlink/cmeth-adapter	Patch
@chainlink/tp-adapter	Patch
@chainlink/kaiko-state-adapter	Patch
@chainlink/deutsche-boerse-adapter	Patch
@chainlink/ftse-sftp-adapter	Patch
@chainlink/aleno-adapter	Patch
@chainlink/gmx-tokens-adapter	Patch
@chainlink/cfbenchmarks-adapter	Patch
@chainlink/glv-token-adapter	Patch
@chainlink/nexus-kiln-adapter	Patch
@chainlink/onre-adapter	Patch
@chainlink/moonbeam-address-list-adapter	Patch
@chainlink/view-starknet-latest-answer-adapter	Patch
@chainlink/blocksize-capital-state-adapter	Patch
@chainlink/polkadot-balance-adapter	Patch
@chainlink/securitize-adapter	Patch
@chainlink/tradinghours-adapter	Patch
@chainlink/data-engine-adapter	Patch
@chainlink/finage-adapter	Patch
@chainlink/wbtc-address-set-adapter	Patch
@chainlink/stader-address-list-adapter	Patch
@chainlink/ion.au-adapter	Patch
@chainlink/exchange-copter-adapter	Patch
@chainlink/nav-generic-adapter	Patch
@chainlink/ondo-calculated-adapter	Patch
@chainlink/m0-adapter	Patch
@chainlink/icap-adapter	Patch
@chainlink/token-allocation-adapter	Patch
@chainlink/gold-adapter	Patch
@chainlink/bsol-price-adapter	Patch
@chainlink/crypto-volatility-index-adapter	Patch
@chainlink/savax-price-adapter	Patch
@chainlink/set-token-index-adapter	Patch
@chainlink/xsushi-price-adapter	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mxiao-cll]

How do you plan to release all these?

[mxiao-cll]

In the framework PR, we should also update the EA generator to include sensitive: false in the generated config

[johnnymugs]

@mxiao-cll In an ideal world, these changes just ship when other new changes to an EA go out. Do you have a recommendation for how to do that?

[mxiao-cll]

@mxiao-cll In an ideal world, these changes just ship when other new changes to an EA go out. Do you have a recommendation for how to do that?

In this case, do not create a changeset

[mxiao-cll]

It is ok to not create a changeset because there is no material change here

[dskloetc]

I think you won't be allowed to merge when changing source files without changeset. And I don't see the problem with having a patch changeset for these.

But putting all or many EAs in the same changeset file will make it impossible to release any of these EAs individually. So ideally there will be a separate changset file per EA. And to be honest, I think it would even be cleaner to have a separate PR per EA. That way each one can be reviewed individually and get the attention it deserves. And can be easily reverted individually if needed. I'd be happy to split the PR into separate small PRs if you don't have time for that.

[dskloetc]

You have a build error:

2026-02-24T01:38:50.1869087Z ##[error]packages/sources/deutsche-boerse/src/transport/protobuf-wstransport.ts(16,3): error TS2416: Property 'startHeartbeat' in type 'ProtobufWsTransport<T>' is not assignable to the same property in base type 'WebSocketTransport<T>'.
2026-02-24T01:38:50.1871768Z   Type '(intervalMs: number, cacheMaxAge: number) => void' is not assignable to type '(context: EndpointContext<T>) => void'.
2026-02-24T01:38:50.1873051Z     Target signature provides too few arguments. Expected 2 or more, but got 1.

I think this happens because @mxiao-cll added startHeartbeat to WebSocketTransport in smartcontractkit/ea-framework-js#642 but ProtobufWsTransport in deutsch-boerse, which extends WebSocketTransport already had a startHeartbeat method and now they conflict. @mxiao-cll can you assist @johnnymugs with this?

Meanwhile, I recommend that you split the PR by starting with a single EA that does not have problems to see that it works.

[mxiao-cll]

Yes, I think we need to re-factor deutsche-boerse a bit to use the new framework heartbeat in order to bump the version