Deep-Dive Debugging Guide

Wingify Feature Experimentation (FE) allows developers and product teams to monitor, identify, and resolve SDK-related issues directly within the Wingify dashboard

#Overview

When a Wingify Feature Experimentation (FE) SDK integration does not behave as expected, feature flags not evaluating correctly, variables returning defaults, events not tracking, or SDK initialization failing, the root cause is almost always visible through SDK logs or’s built-in error monitoring.

Wingify FE SDKs provide:

• Configurable log levels
• Custom log forwarding support
• Automatic error telemetry to Wingify
• In-app error visibility for debugging

This guide explains how to systematically debug SDK integrations across:

• Server-side SDKs (Node, Java, Python, Go, .NET, PHP, Ruby)
• Client-side SDKs (JavaScript, React)
• Mobile SDKs (iOS, Android, React Native, Flutter)

#Observability Flow (How Debugging Works)

Every Wingify FE SDK emits three streams of diagnostic signals:

flowchart LR
    A[Application Runtime] --> B[Wingify FE SDK Core]

    B --> C[Structured Logs]
    B --> D[Custom Logger Adapter]
    B --> E[Error Telemetry Pipeline]

    E --> F[Wingify Aggregation Service]
    F --> G[Wingify Dashboard Debug View]

This allows remote diagnosis without SSH or mobile device log access.

#What Happens Internally

1. Your application calls the Wingify FE SDK.
2. SDK generates logs based on the configured log level.
3. Logs are:
   • Printed to standard output
   • Optionally forwarded to your logging system
   • ERROR-level logs automatically sent to Wingify
4. Wingify aggregates SDK errors and displays them inside the dashboard.

#SDK Logging Fundamentals

All Wingify FE SDKs from Wingify:

• Log errors to standard output by default
• Default log level: ERROR
• Support configurable log levels:
  • ERROR
  • WARNING
  • INFO
  • DEBUG

#What Each Level Provides

#Default Behavior

If you don't configure anything at your end:

• Only ERROR logs are printed
• ERROR logs are also sent to Wingify automatically

#Enabling Verbose Logging (Critical First Step)

When debugging, change the log level to DEBUG.

Below is a Node.js example of how to configure log level.

const { init, LogLevelEnum } = require('wingify-fme-node-sdk');

const wingifyClient = init({
  sdkKey: 'YOUR_SDK_KEY',
  logger: {
    level: LogLevelEnum.DEBUG
  }
});

#What You See in DEBUG Mode

• SDK initialization lifecycle
• Settings file fetch & polling
• Rule evaluation steps
• Targeting condition checks
• Bucketing logic
• Variable resolution
• Network calls and retries
• Event dispatch payloads

This is the most important step when troubleshooting incorrect flag evaluations.

#Forwarding Logs to Your Monitoring System

All FE SDKs allow custom logger integration.

Instead of printing to the console, forward logs to:

• Datadog
• ELK Stack
• Splunk
• CloudWatch
• Any structured logging framework

#Example of custom logger

const customLogger = {
  log: (level, message) => {
    myDatadogLogger.log(level, message);
  }
};

const wingifyClient = init({
  sdkKey: 'YOUR_SDK_KEY',
  logger: customLogger
});

#Why This Is Recommended

• Centralized observability
• Correlate SDK failures with deployments
• Identify environment-specific issues
• Monitor retry spikes

In production systems, this is far more powerful than console logging alone.

#Automatic SDK Error Telemetry (Server + Client Side)

Wingify FE SDKs automatically send ERROR-level logs to Wingify servers across:

• Server-side SDKs
• JavaScript / React SDK
• Mobile SDKs (iOS, Android, React Native)

This means:

No additional configuration is required.

#Using Wingify Advanced Debugging Dashboard

Inside the Wingify application, SDK-generated errors are aggregated and made searchable.

You can:

• View Critical Errors
• Initialization failures
• Invalid SDK key
• Missing feature key
• Network errors
• Retry attempts
• Timeout failures

#Understand Scope

Compare:

• Total events
• Unique users affected

This helps determine whether an issue is:

• Isolated to one user
• Environment-specific
• Widespread

#Filter Errors By

• Date range
• SDK name and version
• Environment
• Error category

#Drill Down Into Specific Errors

Inspect:

• Raw event payload
• Timestamp
• Affected user IDs

#Step-by-Step Troubleshooting Playbook

#Step 1 — Verify SDK Initialization

Enable DEBUG logs and confirm:

• SDK key is correct
• Settings file fetch succeeded

If initialization fails:

• Validate SDK key for the correct environment
• Check outbound network access
• Verify firewall/proxy restrictions

#Step 2 — Validate Feature Key

Common mistake:

wingifyClient.getFlag('wrong_feature_key', context);

DEBUG logs will show:

• Feature not found
• Returning default value

Confirm:

• Feature key matches exactly
• Feature is enabled
• Correct environment

#Step 3 — Validate User Identity

Inconsistent user IDs cause bucketing inconsistencies.

Check:

• Same userId used across calls
• No random UUID per request
• Attribute types match targeting rules

DEBUG logs show:

• Which targeting condition failed
• Bucketing result
• Variation assignment

#Step 4 — Check Network Calls & Retries

If events are not recorded:

Look for:

• Retry attempts
• Timeout logs
• Network failures

Common causes:

• Browser/Edge navigation terminating request
• Server shuts down before flush
• Firewall blocking Wingify endpoints

#Step 5 — Correlate Local Logs with Wingify Dashboard

After enabling logs:

• Open Wingify Application
• Navigate to Website and Apps under Configurations section from the left navbar
• Select the Feature Experimentation Default Project and switch to Logs tab
• Filter by environment
• Inspect error category

If errors appear there:

• SDK is sending telemetry successfully

If not:

• Environment mismatch likely
• SDK key may be incorrect

#Common Integration Pitfalls

• Using the wrong SDK key
• Creating a new SDK instance per request
• Calling getFlag before initialization
• Inconsistent user ID
• Firewall blocking outbound calls

#Recommended Production Debugging Strategy

For stable production systems:

1. Keep log level at ERROR
2. Temporarily enable DEBUG in an affected environment
3. Forward logs to centralized logging
4. Compare dashboard telemetry with application logs
5. Identify spike patterns before rollback

#Three-Layer Debugging Model

flowchart TB
    A[Application Logs]
    B[Infrastructure Logs]
    C[Wingify SDK Error Telemetry]

    A --> D[Root Cause Analysis]
    B --> D
    C --> D

When combined:

• Application logs show execution flow
• Infrastructure logs show environment failures
• Wingify telemetry shows SDK-specific errors

Together, they eliminate blind spots.

#When to Contact Support

If:

• Errors are visible but unclear.
• Initialization fails despite correct configuration.
• Network issues persist after validation.
• Dashboard shows repeated retry spikes.

Collect the following before contacting support:

• SDK name and version
• Environment (production/staging)
• Sample DEBUG logs
• Timestamp of issue
• Feature key involved
• User ID (if reproducible)

Providing these details significantly reduces resolution time.