Performance & Limitations

Performance Considerations

JavaScript execution adds overhead compared to native OTTL operations. Measured performance impact from testing complex transformations (including nested objects, arrays, conditionals, and JSON operations):

• CPU impact: +0.3% (measured: baseline 5.0% → 5.3%)
• Memory impact: +1MB (measured: baseline 125MB → 126MB)
• Latency impact: +3ms p95 (measured: baseline 88ms → 91ms p95)
• Throughput: No measurable impact in testing

Performance may vary with:

• Complexity of JavaScript operations
• Volume and frequency of events
• Agent resource allocation
• Concurrent pipeline processing

For high-volume pipelines (>1000 logs/sec), prefer native OTTL for simple operations and reserve edx_code for transformations that genuinely require JavaScript capabilities.

Type Conversion

Fields from parsed JSON may arrive as strings and require explicit type conversion before numeric operations. When using the Code Processor, you typically extract and convert fields using an OTTL Transform processor first:

In the Code Processor UI, you would write:

item['attributes']['ab_flag'] = item['attributes']['test_id'] % 2 === 0 ? 'A' : 'B';

In Pipeline YAML, this becomes:

# First, extract and convert with OTTL Transform:
- type: ottl_transform
  statements: |
    set(attributes["test_id"], Int(body["test_id"]))    

# Then, Code Processor generates this:
- type: ottl_transform
  metadata: '{"id":"code-transform","type":"ottl_transform","name":"Code Processor"}'
  data_types:
  - log
  statements: edx_code("item['attributes']['ab_flag'] = item['attributes']['test_id'] % 2 === 0 ? 'A' : 'B';")

Syntax Validation and Error Handling

Syntax Validation (v2.6.0)

Edge Delta validates JavaScript syntax at configuration time, before deployment. Invalid syntax is caught by both CLI and GUI interfaces and prevents configuration from being saved or deployed:

// ❌ This will be REJECTED during validation
item['attributes']['test'] = ;  // SyntaxError: Unexpected token ;

// Validation error message:
// "JavaScript compilation failed: SyntaxError: (anonymous): Line 7:34 Unexpected token ;"

Both CLI and GUI validation consistently block syntax-invalid JavaScript from reaching agents.

Runtime Error Handling

While syntax errors are blocked at validation time, runtime errors (accessing undefined properties, type mismatches, etc.) are not yet fully tested. Best practices for error handling:

1. Check for field existence before accessing:

   if (item['attributes']['field']) {
     // Use field safely
     item['attributes']['processed'] = item['attributes']['field'].toUpperCase();
   }
   

2. Initialize fields with OTTL where clauses (in a separate OTTL Transform processor):

   - type: ottl_transform
     statements: |
       set(attributes["field"], "default") where attributes["field"] == nil    
   

3. Use null-safe operators:

   item['attributes']['result'] = item['attributes']['field'] || 'default';
   

Template Literal Escaping

Template literals work correctly in the Code Processor:

// Using ${} inside template literal
item['attributes']['msg'] = `Value: ${item['attributes']['value']}`;

// Apostrophes work naturally
item['attributes']['msg'] = `It's working`;

Comparison: OTTL vs Code Processor

When to Use Code Processor

Use the Code Processor when you need:

• Complex conditionals - Nested if/else logic or switch statements
• Array transformations - map, filter, reduce, sorting, slicing
• Iterative processing - forEach, while loops, dynamic iteration
• Complex date arithmetic - Date calculations, formatting, timezone handling
• Dynamic object manipulation - Creating nested structures with conditionals
• Multi-step logic in one place - Consolidating operations that would require many OTTL statements

When to Use OTTL + Extensions

Use OTTL (with EdgeDelta extensions) when you need:

• Simple field operations - set, delete, merge, rename
• Null coalescing - EDXCoalesce for fallback values
• Inline conditionals - EDXIfElse for simple ternary logic
• Pattern extraction - ExtractPatterns, EDXExtractPatterns
• Key-value parsing - ParseKeyValue, EDXParseKeyValue
• Environment variables - EDXEnv for config injection
• Compression/Encryption - EDXCompress, EDXEncrypt, EDXDecrypt
• External data - EDXRedis for enrichment
• Performance-critical paths - Native Go speed for high-volume processing
• Type introspection - EDXDataType for runtime type checking

Areas Under Active Development

The following aspects of edx_code are under active testing and development:

Runtime Error Handling

• Behavior when accessing undefined properties
• Timeout handling for infinite loops
• Type mismatch error handling

Additional Syntax Patterns

• Various quote escaping patterns
• Complex nested expressions
• Edge cases in YAML formatting

Performance at Scale

• High-volume processing (1000+ logs/sec)
• Memory efficiency optimizations
• Throughput improvements

Check the Edge Delta release notes for updates as these capabilities mature.

Best Practices

• Start Simple: Begin with basic operations and gradually add complexity as you understand the behavior
• Type Convert Early: Use OTTL Int(), Double(), or String() functions to convert types before edx_code operations
• Null Safety: Always check for field existence before accessing nested properties
• Avoid Reinventing: Use native OTTL for simple operations; reserve edx_code for complex transformations
• Test Incrementally: Deploy changes to a test environment and verify output before production
• Monitor Performance: Track pipeline latency and throughput when introducing edx_code transformations
• Document Intent: Add comments to explain complex JavaScript logic for future maintainers
• Validate Output: Ensure transformed data meets downstream system requirements
• Keep Blocks Small: Break complex logic into multiple edx_code calls for easier debugging
• Use Block Syntax: For multi-step operations, use {} to group statements and declare local variables