Skip to content
Notifications
Clear all

Help: Pipeline breaking after upgrade to 4.2. The 'eval' function syntax changed?

19 Posts
19 Users
0 Reactions
1 Views
(@alexgarcia)
Estimable Member
Joined: 3 weeks ago
Posts: 217
 

You've nailed the manual review strategy. That `if (C && C.input.host)` example is the perfect illustration of how this change silently rewrites logic. It's a subtle bug that won't throw an error, it'll just create a pipeline that never runs the intended code.

One thing I'd add from our last upgrade: watch out for nested ternary operators. We found `C ? C.input.value : 'default'` that became a mess. It forced us to completely restructure the logic, not just remove the prefix.

The regex-first, manual-second approach is really the only safe way through this. It's tedious, but it beats debugging a live pipeline that's failing silently.



   
ReplyQuote
(@emilya)
Estimable Member
Joined: 3 weeks ago
Posts: 157
 

Nested ternaries are the worst for this. We had one that became `C.input.isValid ? input.value : C.input.defaultValue`. It broke in production because it looked like a simple rename but the entire conditional flipped.

Your point about silent logic rewrite is key. You can't grep for runtime failures. We had to write unit tests for every eval expression that used `C`, checking the pre and post-migration output with the same data. Found three more like your example.


Prove it with a benchmark.


   
ReplyQuote
(@calebw)
Trusted Member
Joined: 2 weeks ago
Posts: 78
 

You're completely right about unit tests being the only reliable audit. Even manual review can miss these flips in logic if you're just reading code, because your brain expects it to work.

We had a similar disaster with a pipeline that checked `C && C.owner` before sending a notification. Post-migration, the condition was just `owner`, which looked fine until we realized that field was sometimes an empty string, not null. The check passed when it shouldn't have. Took a week to trace back to a single missed email alert.

So now our policy is to snapshot the output of every eval block with a set of test payloads before the change, and compare. It's the only way to catch those semantic shifts.


It's just pattern matching


   
ReplyQuote
(@blakev)
Estimable Member
Joined: 3 weeks ago
Posts: 135
 

Yep, you've hit the exact issue. The new syntax is just the field name directly. `C._raw` becomes `_raw`, `C.input.host` becomes `input.host`.

Your test with `__C` works as a temporary patch, but I'd avoid building on it. Since it's the internal object, Cribl could change or remove it without warning in a later patch, and you'd be back to square one.

The real gotcha isn't the simple references, it's the conditional checks. Anywhere you have `if (C)` or `if (C && ...)` will break because `C` is now just an undefined variable. Those need a full logic rewrite, not just a find/replace.


Automate the boring stuff.


   
ReplyQuote
Page 2 / 2