# features/config_hot_reloading.feature
Feature: Config Hot Reloading
  The system should support selective hot reloading of configuration changes

  Scenario: Hot reloading logging level changes
    Given the server is running with config file monitoring enabled
    When I update the logging level to "debug" in the config file
    Then the logging level should be updated without restart
    And debug logs should appear in the output

  Scenario: Hot reloading feature flags
    Given the server is running with config file monitoring enabled
    And the v2 API is disabled
    When I enable the v2 API in the config file
    Then the v2 API should become available without restart
    And v2 API requests should succeed

  Scenario: Hot reloading telemetry sampling settings
    Given the server is running with config file monitoring enabled
    And telemetry is enabled
    When I update the sampler type to "parentbased_traceidratio" in the config file
    And I set the sampler ratio to "0.5" in the config file
    Then the telemetry sampling should be updated without restart
    And the new sampling settings should be applied

  Scenario: Hot reloading JWT TTL
    Given the server is running with config file monitoring enabled
    And JWT TTL is set to 1 hour
    When I update the JWT TTL to 2 hours in the config file
    Then the JWT TTL should be updated without restart
    And new JWT tokens should have the updated expiration

  Scenario: Attempting to hot reload non-reloadable settings should be ignored
    Given the server is running with config file monitoring enabled
    When I update the server port to 9090 in the config file
    Then the server port should remain unchanged
    And the server should continue running on the original port
    And a warning should be logged about ignored configuration change

  Scenario: Invalid configuration changes should be handled gracefully
    Given the server is running with config file monitoring enabled
    When I update the logging level to "invalid_level" in the config file
    Then the logging level should remain unchanged
    And an error should be logged about invalid configuration
    And the server should continue running normally

  Scenario: Config file monitoring should handle file deletion gracefully
    Given the server is running with config file monitoring enabled
    When I delete the config file
    Then the server should continue running with last known good configuration
    And a warning should be logged about missing config file

  Scenario: Config file monitoring should handle file recreation
    Given the server is running with config file monitoring enabled
    And I have deleted the config file
    When I recreate the config file with valid configuration
    Then the server should reload the configuration
    And the new configuration should be applied

  Scenario: Multiple rapid configuration changes should be handled
    Given the server is running with config file monitoring enabled
    When I rapidly update the logging level multiple times
    Then all changes should be processed in order
    And the final configuration should be applied
    And no configuration changes should be lost

  Scenario: Configuration changes should be audited
    Given the server is running with config file monitoring enabled
    And audit logging is enabled
    When I update the logging level to "info" in the config file
    Then an audit log entry should be created
    And the audit entry should contain the previous and new values
    And the audit entry should contain the timestamp of the change