Strip error messages from hook telemetry

[bwoebi]

No description provided.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.85%. Comparing base (9298487) to head (8669fe1).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3449      +/-   ##
==========================================
- Coverage   61.89%   61.85%   -0.04%     
==========================================
  Files         141      141              
  Lines       12501    12501              
  Branches     1633     1633              
==========================================
- Hits         7737     7733       -4     
- Misses       4042     4046       +4     
  Partials      722      722              

see 2 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9298487...8669fe1. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2025-10-17 13:21:50

Comparing candidate commit 8669fe1 in PR branch bob/hook-error-telem with baseline commit 9298487 in branch master.

Found 1 performance improvements and 8 performance regressions! Performance is the same for 184 metrics, 1 unstable metrics.

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟥 execution_time [+3.182µs; +4.718µs] or [+3.003%; +4.453%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1

• 🟥 execution_time [+101.425ns; +152.375ns] or [+8.702%; +13.074%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1-opcache

• 🟥 execution_time [+197.250ns; +352.150ns] or [+2.763%; +4.934%]

scenario:SamplingRuleMatchingBench/benchRegexMatching2

• 🟥 execution_time [+67.864ns; +133.136ns] or [+5.728%; +11.237%]

scenario:SamplingRuleMatchingBench/benchRegexMatching3

• 🟥 execution_time [+97.636ns; +140.964ns] or [+8.359%; +12.069%]

scenario:SamplingRuleMatchingBench/benchRegexMatching4

• 🟥 execution_time [+51.421ns; +108.979ns] or [+4.341%; +9.200%]

scenario:SamplingRuleMatchingBench/benchRegexMatching4-opcache

• 🟥 execution_time [+169.479ns; +316.321ns] or [+2.395%; +4.469%]

scenario:SpanBench/benchOpenTelemetryAPI

• 🟥 mem_peak [+1.703MB; +1.709MB] or [+4.122%; +4.136%]

scenario:TraceSerializationBench/benchSerializeTrace

• 🟩 execution_time [-29.858µs; -17.742µs] or [-6.732%; -4.000%]

[bouwkast]

Thanks

Just going to add some context here in the PR for the future feel free to correct me :)

We didn't think there would be much value / feasibility in attempting to rework the existing design to log differently or in more locations.

Opting to strip out the most dynamic bit, but leave the rest there to attempt to keep some semblance of usability (even if it is very little usefulness)
We can follow up in the future to attempt to determine how we can improve this.