Gabriel Radureau
dbadff58e2
- Add STATE_TRACER_README.md with full documentation - Add state_tracer.go for per-process BDD execution tracing to $TMPDIR - Integrate tracing hooks in suite.go (SCENARIO_START/END, JWT_RESET, DB_CLEANUP) - Fix config_steps.go: increase file recreation delay to 1100ms for 1s polling interval - Fix config_test.go: update expected values to match current implementation - Document findings: sequential per-feature execution, shared DB, in-memory JWT secrets - Identify root causes of intermittent failures Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
73 lines
3.5 KiB
Gherkin
73 lines
3.5 KiB
Gherkin
# 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 |