feat: unified stack trace configuration from agent, in-code and env vars

[abhilash-sivan]

refs https://jsw.ibm.com/browse/INSTA-63750

Current PR

• Accept stack trace configuration (tracing.global.stack-trace-length and stack-trace) from the agent.
• Support in-code configuration via tracing.global.stackTraceLength and stackTrace, while keeping tracing.stackTraceLength for backward compatibility.
• Configuration precedence (highest to lowest):
  agent → tracing.global.stackTraceLength → tracing.stackTraceLength → env var → default
• Introduce a maximum limit of 500 for stackTraceLength; the default remains 10.
• Apply agent configuration when present.
• Enforce the configured stackTraceLength limit in setErrorDetails to demonstrate that the limit is applied.

Next PR

• Extend the stackTraceLength limit to the getStackTrace function and add the required tests. done in this pr
• Apply the stackTrace mode and add corresponding tests.

[kirrg001]

Same here. Why do we have to validate here again that stackTraceLength is a number?

[abhilash-sivan]

This is a similar case of #2235 (comment)

We can't just check the existence because of the possible 0 case.

[kirrg001]

This extra check is only needed because we dont set the default value after the failed validation?

[abhilash-sivan]

Ah, in a recent change I updated the normaliser to return null when no valid data is parsed.
This should have allowed us to move away from type checks and instead use a simple != null check.

However, there are some edge cases to consider.

For example, when a legacy configuration is set with an invalid value:

const config = coreConfig.normalize({ tracing: { stackTraceLength: {} } });
expect(config.tracing.stackTraceLength).to.equal(10);

In this case, validation fails and the normaliser is not called.
Because of that, the value remains defined (but invalid), and the != null check passes.
As a result, we never fall back to the default value, which is incorrect.

To handle edge cases like {}, [], or [18], we still need to perform a type check.
This is specific to stackTraceLength only because legacy support writes directly to the same field we later normalise.

This issue does not apply to stackTrace mode, since that value is derived from tracing.global.stackTrace, and when the user provides an invalid value, we correctly fall back to the default.

[kirrg001]

Because of that, the value remains defined (but invalid), and the != null check passes.

If validation fails, we have to set defaults!

[kirrg001]

If you have defined isLegacyLengthDefined -> we show the warning. It doesn't matter if customer already uses the new one.

[abhilash-sivan]

Okay, updated 👍

[kirrg001]

The features ignore-endpoints and disable used the community config order. This slipped through my review. We should have continued with our Node.js config order. Now we are in a mixed state, which is not right.

As we do not want to change ignore-endpoints and disable features, we decided change the order in our tracer asap (Q1) and release v6. We have that on our board anyway for a while now (https://jsw.ibm.com/browse/INSTA-817).

That means (I am sorry) this PR also has to follow the new community order.

cc @aryamohanan cc @abhilash-sivan

[abhilash-sivan]

Agreed. Np., Will do

[aryamohanan]

100% make sense.

[kirrg001]

Pre-approving. Just the new order is missing.

[aryamohanan]

Great work 👏

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
83.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud