9753b31c7e
CI / quality (push) Successful in 36s
CI / lint (push) Successful in 38s
CI / typecheck (push) Successful in 49s
CI / security (push) Successful in 51s
CI / integration_tests (push) Successful in 55s
CI / unit_tests (push) Successful in 3m35s
CI / build (push) Successful in 33s
CI / coverage (push) Successful in 3m36s
CI / status-check (push) Successful in 3s
Add 13 BDD scenarios covering previously uncovered code paths: - SAFE_BUILTINS validation (sandbox.py: 0% → 100%) - ConfigurationError re-raise path (config.py: 99.3% → 100%) - CLI hello/main functions (cli.py: 72.7% → 90.9%) - GraphState message truncation (state.py: 98.7% → 100%) - ProgressBarManager update/context rendering (progress.py: 0% → 87.7%) - MessageRouter regex/exact/contains routing (message_router.py: 0% → 59.4%) - RoutingAdapter parse_routing_command (routing_adapter.py) - DynamicRouterNode pattern-based routing (dynamic_router.py) - EnhancedTemplateRegistry unknown template type (enhanced_registry.py: 99.2%) - CompositeAgent null-graph error path (composite.py: 97.8% → 98.6%) Cover routing_adapter.py (17% → 100%): all GOTO/ROUTE patterns, create_routing_node, create_conditional_router, dynamic config conversion. Cover dynamic_router.py (21% → 87%): execute with empty/dict/string messages, extract_message with colon parsing, config creation, graph extension with edge generation. Cover message_router.py (59% → 78%): regex, exact, contains, prefix, suffix match types, invalid regex handling, non-string message, set_state. Exercise Node._prepare_conversation_history with invalid configs, _runtime error paths, _execute_message_router with rules, _execute_agent with current_message and metadata propagation, _execute_function with dynamic_router, and _execute_conditional with content_contains/content_not_contains/content_starts_with and custom condition types. Improves nodes.py from 71.3% to 72.5%. Exercise PureGraphConfig, PureLangGraph init with dict/config, RxPyLangGraphBridge registration/connection/lookup, ReactiveStreamRouter operator creation and condition functions, ReactiveConfigParser config/route/graph parsing, ToolAgent tool execution with JSON, space-separated, single, file_read, progress_bar invocations, and ReactiveCleverAgentsApp init/dispose/visualization.
138 lines
5.4 KiB
Gherkin
138 lines
5.4 KiB
Gherkin
Feature: Graph State Update Modes, Serialization, StateManager, and Time Travel
|
|
As a developer
|
|
I want graph states to support replace, merge, and append update modes, serialize to dict, checkpoint, and support time travel
|
|
So that state management is consistent across persistence boundaries and supports audit trails
|
|
|
|
Background:
|
|
Given the state management system is available
|
|
|
|
Scenario: GraphState replace update mode
|
|
Given I have a GraphState instance
|
|
And I have updates with replace mode
|
|
When I update the state with REPLACE mode
|
|
Then the state should be replaced completely
|
|
And only valid attributes should be updated
|
|
|
|
Scenario: GraphState merge update mode with dictionaries
|
|
Given I have a GraphState with existing metadata
|
|
And I have dictionary updates for merge mode
|
|
When I update the state with MERGE mode
|
|
Then dictionaries should be merged properly
|
|
And existing values should be preserved
|
|
|
|
Scenario: GraphState merge update mode with lists
|
|
Given I have a GraphState with existing messages
|
|
And I have list updates for merge mode
|
|
When I update the state with MERGE mode
|
|
Then lists should be extended properly
|
|
And existing messages should be preserved
|
|
|
|
Scenario: GraphState merge update mode with simple values
|
|
Given I have a GraphState with simple values
|
|
And I have simple value updates
|
|
When I update the state with MERGE mode
|
|
Then simple values should be replaced
|
|
|
|
Scenario: GraphState append update mode with lists
|
|
Given I have a GraphState with existing list data
|
|
And I have new items to append
|
|
When I update the state with APPEND mode
|
|
Then items should be appended to lists
|
|
And single items should be appended as well
|
|
|
|
Scenario: GraphState to_dict conversion
|
|
Given I have a GraphState with various data
|
|
When I convert the state to dictionary
|
|
Then all fields should be present in the dictionary
|
|
And the dictionary should match expected structure
|
|
|
|
Scenario: GraphState from_dict creation
|
|
Given I have a state dictionary
|
|
When I create a GraphState from the dictionary
|
|
Then the GraphState should have correct field values
|
|
And all data should be properly initialized
|
|
|
|
Scenario: StateManager with checkpoint directory creation
|
|
Given I specify a checkpoint directory path
|
|
When I create a StateManager with checkpointing
|
|
Then the checkpoint directory should be created
|
|
And checkpointing should be enabled
|
|
|
|
Scenario: StateManager time travel disabled
|
|
Given I create a StateManager without time travel
|
|
When I try to use time travel functionality
|
|
Then time travel should return None
|
|
And no history should be maintained
|
|
|
|
Scenario: StateManager history trimming
|
|
Given I have a StateManager with time travel enabled
|
|
And I set a small max history size
|
|
When I make many state updates
|
|
Then the history should be trimmed to max size
|
|
And older snapshots should be removed
|
|
|
|
Scenario: StateManager checkpoint saving
|
|
Given I have a StateManager with checkpointing enabled
|
|
And I set a small checkpoint interval
|
|
When I make multiple state updates
|
|
Then checkpoints should be saved automatically
|
|
And checkpoint files should be created
|
|
|
|
Scenario: StateManager checkpoint loading
|
|
Given I have a StateManager with a checkpoint file
|
|
When I load the checkpoint
|
|
Then the state should be restored from checkpoint
|
|
And the update count should be restored
|
|
And the state stream should emit the loaded state
|
|
|
|
Scenario: StateManager latest checkpoint detection
|
|
Given I have multiple checkpoint files
|
|
When I get the latest checkpoint
|
|
Then the most recent checkpoint should be returned
|
|
And it should be based on file modification time
|
|
|
|
Scenario: StateManager latest checkpoint with no files
|
|
Given I have a checkpoint directory with no files
|
|
When I get the latest checkpoint from empty directory
|
|
Then None should be returned for latest checkpoint
|
|
|
|
Scenario: StateManager time travel functionality
|
|
Given I have a StateManager with time travel enabled
|
|
And I have made several state updates
|
|
When I travel back in time
|
|
Then the state should revert to previous version
|
|
And the state stream should emit the historical state
|
|
|
|
Scenario: StateManager time travel beyond history
|
|
Given I have a StateManager with limited history
|
|
When I try to travel back more steps than available
|
|
Then it should travel back to the earliest available state
|
|
And time travel should not cause errors
|
|
|
|
Scenario: StateManager get state observable
|
|
Given I have a StateManager
|
|
When I get the state observable
|
|
Then it should return an RxPy observable
|
|
And it should emit state changes
|
|
|
|
Scenario: StateManager clear history
|
|
Given I have a StateManager with some history
|
|
When I clear the history
|
|
Then the history should be empty
|
|
And time travel should not be possible
|
|
|
|
Scenario: StateManager reset functionality
|
|
Given I have a StateManager with modified state
|
|
When I reset the state manager
|
|
Then the state should return to initial values
|
|
And the update count should reset to zero
|
|
And the history should be cleared
|
|
And the state stream should emit the reset state
|
|
|
|
Scenario: StateManager reset with custom initial state
|
|
Given I have a StateManager
|
|
And I have a custom initial state
|
|
When I reset with the custom initial state
|
|
Then the state should match the custom initial state
|
|
And all counters should be reset
|