Configuration migration fallbacks

When configuration structures evolve, implement fallback mechanisms to handle both old and new formats gracefully. This ensures backward compatibility during transitions and prevents breaking changes.

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

When configuration structures evolve, implement fallback mechanisms to handle both old and new formats gracefully. This ensures backward compatibility during transitions and prevents breaking changes.

Key practices:

  • Check for new configuration format first, then fall back to legacy format
  • Update conversion logic when units or data types change
  • Provide clear migration paths for deprecated configuration options

Example from query configuration migration:

// Check new format first, then fallback to legacy
metricName: queryData.aggregation?.[0].metricName || queryData.aggregateAttribute?.key

Example from TTL configuration update:

// Handle unit conversion during configuration migration
setLogsCurrentTTLValues((prev) => ({
  ...prev,
  logs_ttl_duration_hrs: logsTotalRetentionPeriod || -1,
  default_ttl_days: logsTotalRetentionPeriod 
    ? logsTotalRetentionPeriod / 24 // convert Hours to days
    : prev.default_ttl_days
}));

This approach maintains system stability while allowing configuration schemas to evolve over time.

Source discussions