-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[APPSEC-55378] Rework Processor::Context logging and telemetry #4035
[APPSEC-55378] Rework Processor::Context logging and telemetry #4035
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4035 +/- ##
==========================================
- Coverage 97.86% 97.85% -0.01%
==========================================
Files 1321 1321
Lines 79343 79318 -25
Branches 3936 3904 -32
==========================================
- Hits 77647 77616 -31
- Misses 1696 1702 +6 ☔ View full report in Codecov by Sentry. |
f652db4
to
fe27edb
Compare
else | ||
v.nil? ? true : v.empty? | ||
end | ||
next false if v.is_a?(TrueClass) || v.is_a?(FalseClass) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we actually don't need this line, and this whole reject!
could be changed to:
input.compact!.reject(&:empty?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the only thing I am not sure is whether we can expect that every non-nil value responds to empty?
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and it's also fine to leave this block like it is, to reduce amount of changes in this PR
BenchmarksBenchmark execution time: 2024-10-28 18:26:02 Comparing candidate commit dc1b88f in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 23 metrics, 2 unstable metrics. scenario:library - Gem loading
|
if LIBDDWAF_SUCCESSFUL_EXECUTION_CODES.include?(result.status) | ||
Datadog.logger.debug { "libddwaf execution result: #{result.inspect}" } | ||
else | ||
message = "libddwaf execution error: #{result.status.inspect} with #{result.inspect}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After discussion with @TonyCTHsu we agreed to change it into the following:
message = "libddwaf:1.14.0 execution error: #{result.status.inspect}"
we will drop result.inspect
to balance cardinality and also it doesn't bring much value.
fe27edb
to
d1c7ee9
Compare
d1c7ee9
to
0311964
Compare
What does this PR do?
This PR centralizes debug handling of the WAF execution into a single place
Processor::Context
Motivation:
During upgrades we would like to know when we've made a mistake and be alerted about it upfront. We double-checked existing result codes of the WAF execution and removed outdated. At the same time if we use Telemetry error reporting to deliver unhandled errors such as:
DDWAF_ERR_INTERNAL
(ruby::err_internal
)DDWAF_ERR_INVALID_OBJECT
(ruby::err_invalid_object
)DDWAF_ERR_INVALID_ARGUMENT
(ruby::err_invalid_argument
)See full list
Change log entry
Not needed.
Additional Notes:
This PR could be released without
libddwaf-rb
upgradeHow to test the change?
CI is enough.