Skip to content

Conversation

@thomhurst
Copy link
Owner

Fixes #3961

@claude
Copy link
Contributor

claude bot commented Dec 2, 2025

Claude finished @thomhurst's task —— View job


Code Review Complete

Reviewing the object lifecycle management and property injection refactoring. This is a significant change with 1003 additions and 1206 deletions across 15 files.

Review Tasks:

  • Read repository guidelines (CLAUDE.md)
  • Analyze deleted files to understand removed functionality
  • Review new files for architecture and design patterns
  • Examine modified files for integration points
  • Check for dual-mode implementation compliance
  • Evaluate performance implications
  • Look for potential bugs and security issues
  • Assess test coverage impact
  • Provide comprehensive feedback

✅ Overall Assessment: EXCELLENT REFACTORING

This is a well-executed consolidation that improves maintainability and follows solid architectural principles. The refactoring successfully addresses several architectural concerns while maintaining functionality.

🏗️ Architecture Improvements

Consolidation Benefits

  • Before: 5 fragmented services (PropertyInjectionService, DataSourceInitializer, PropertyInitializationOrchestrator, PropertyDataResolver, ObjectRegistrationService)
  • After: 3 cohesive services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Result: Cleaner separation of concerns with clear phase boundaries

Dependency Management

  • ✅ Excellent: Uses Lazy<T> to break circular dependencies without manual Initialize() calls
  • ✅ Clean: Eliminates the fragile two-phase initialization pattern
  • ✅ Type-Safe: Maintains compile-time safety while breaking cycles

Single Responsibility Principle

  • ObjectGraphDiscoveryService: Pure discovery, no modification
  • PropertyInjector: Pure injection, no lifecycle management
  • ObjectLifecycleService: Orchestrates phases but delegates specifics

🚀 Performance Considerations

✅ Positive Performance Impact

  • Eliminates duplicate object graph traversals across multiple services
  • Maintains object pooling for visited dictionaries (TUnit.Engine/Services/PropertyInjector.cs:22)
  • Preserves lazy initialization patterns for expensive operations
  • Uses ConcurrentDictionary for thread-safe caching

⚠️ Minor Performance Note

  • Lazy<T> introduces small overhead, but this is negligible compared to the elimination of duplicate traversals
  • Net performance should be improved due to reduced redundant work

🔒 Security & Robustness

✅ Security Compliance

  • Maintains proper [DynamicallyAccessedMembers] annotations for AOT compatibility
  • Preserves reflection safety patterns from TUnit guidelines
  • No sensitive data exposure in the refactored services

✅ Error Handling

  • Maintains proper null checking and argument validation
  • Preserves exception propagation patterns
  • Uses TaskCompletionSource<bool> for safe async coordination

🎯 Dual-Mode Implementation Compliance

✅ CRITICAL REQUIREMENT MET

This refactoring correctly maintains dual-mode support:

  • Source Generation Mode: Uses pre-compiled metadata via PropertyInjectionPlanBuilder
  • Reflection Mode: Falls back to runtime discovery
  • Integration Point: TUnit.Core/PropertyInjection/PropertyInjectionCache.cs:28 - PropertyInjectionPlanBuilder.Build(type)

The refactoring is service-layer only and doesn't change the dual-mode execution paths, which is architecturally sound.

📝 Code Quality

✅ Strengths

  • Modern C# Patterns: Proper use of ValueTask, file-scoped namespaces, collection expressions
  • Clear Documentation: Comprehensive XML docs explaining architectural decisions
  • Naming: Descriptive class and method names that convey intent
  • Consistent Style: Follows TUnit coding standards

✅ SOLID Principles

  • Single Responsibility: Each new service has a focused purpose
  • Open/Closed: Extensible design with clear interfaces
  • Liskov Substitution: Proper inheritance patterns
  • Interface Segregation: Focused interfaces like IObjectRegistry
  • Dependency Inversion: Uses abstractions and dependency injection

🧪 Test Coverage Impact

⚠️ Recommendation: Update Tests

While the refactoring maintains functionality, consider:

  • Unit tests for new services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Integration tests to verify the phase coordination works correctly
  • Performance benchmarks to validate the optimization claims

🔍 Minor Suggestions

Code Organization

// TUnit.Engine/Services/ObjectLifecycleService.cs:24
// Consider extracting this constant for maintainability
private const int DEFAULT_CONCURRENCY_LEVEL = Environment.ProcessorCount;
private readonly ConcurrentDictionary<object, TaskCompletionSource<bool>> _initializationTasks = 
    new(DEFAULT_CONCURRENCY_LEVEL, 31);

Documentation Enhancement

Consider adding sequence diagrams or flowcharts to document the phase coordination between the three services, especially for future maintainers.

🎉 Excellent Work

This refactoring exemplifies:

  • Strategic thinking: Addressing architectural debt systematically
  • Risk management: Maintaining compatibility while improving structure
  • Performance awareness: Optimizing without sacrificing clarity
  • Standards compliance: Following TUnit's strict guidelines

Recommendation: ✅ APPROVE - This is a high-quality refactoring that significantly improves the codebase architecture.


@claude
Copy link
Contributor

claude bot commented Dec 2, 2025

Claude finished @thomhurst's task —— View job


✅ Overall Assessment: EXCELLENT REFACTORING

This is a well-executed consolidation that improves maintainability and follows solid architectural principles. The refactoring successfully addresses several architectural concerns while maintaining functionality.

🏗️ Architecture Improvements

Consolidation Benefits

  • Before: 5 fragmented services (PropertyInjectionService, DataSourceInitializer, PropertyInitializationOrchestrator, PropertyDataResolver, ObjectRegistrationService)
  • After: 3 cohesive services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Result: Cleaner separation of concerns with clear phase boundaries

Dependency Management

  • ✅ Excellent: Uses Lazy<T> to break circular dependencies without manual Initialize() calls
  • ✅ Clean: Eliminates the fragile two-phase initialization pattern
  • ✅ Type-Safe: Maintains compile-time safety while breaking cycles

Single Responsibility Principle

  • ObjectGraphDiscoveryService: Pure discovery, no modification
  • PropertyInjector: Pure injection, no lifecycle management
  • ObjectLifecycleService: Orchestrates phases but delegates specifics

🚀 Performance Considerations

✅ Positive Performance Impact

  • Eliminates duplicate object graph traversals across multiple services
  • Maintains object pooling for visited dictionaries (TUnit.Engine/Services/PropertyInjector.cs:22)
  • Preserves lazy initialization patterns for expensive operations
  • Uses ConcurrentDictionary for thread-safe caching

⚠️ Minor Performance Note

  • Lazy<T> introduces small overhead, but this is negligible compared to the elimination of duplicate traversals
  • Net performance should be improved due to reduced redundant work

🔒 Security & Robustness

✅ Security Compliance

  • Maintains proper [DynamicallyAccessedMembers] annotations for AOT compatibility
  • Preserves reflection safety patterns from TUnit guidelines
  • No sensitive data exposure in the refactored services

✅ Error Handling

  • Maintains proper null checking and argument validation
  • Preserves exception propagation patterns
  • Uses TaskCompletionSource<bool> for safe async coordination

🎯 Dual-Mode Implementation Compliance

✅ CRITICAL REQUIREMENT MET

This refactoring correctly maintains dual-mode support:

  • Source Generation Mode: Uses pre-compiled metadata via PropertyInjectionPlanBuilder
  • Reflection Mode: Falls back to runtime discovery
  • Integration Point: TUnit.Core/PropertyInjection/PropertyInjectionCache.cs:28 - PropertyInjectionPlanBuilder.Build(type)

The refactoring is service-layer only and doesn't change the dual-mode execution paths, which is architecturally sound.

📝 Code Quality

✅ Strengths

  • Modern C# Patterns: Proper use of ValueTask, file-scoped namespaces, collection expressions
  • Clear Documentation: Comprehensive XML docs explaining architectural decisions
  • Naming: Descriptive class and method names that convey intent
  • Consistent Style: Follows TUnit coding standards

✅ SOLID Principles

  • Single Responsibility: Each new service has a focused purpose
  • Open/Closed: Extensible design with clear interfaces
  • Liskov Substitution: Proper inheritance patterns
  • Interface Segregation: Focused interfaces like IObjectRegistry
  • Dependency Inversion: Uses abstractions and dependency injection

🧪 Test Coverage Impact

⚠️ Recommendation: Update Tests

While the refactoring maintains functionality, consider:

  • Unit tests for new services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Integration tests to verify the phase coordination works correctly
  • Performance benchmarks to validate the optimization claims

🔍 Minor Suggestions

Code Organization

// TUnit.Engine/Services/ObjectLifecycleService.cs:24
// Consider extracting this constant for maintainability
private const int DEFAULT_CONCURRENCY_LEVEL = Environment.ProcessorCount;
private readonly ConcurrentDictionary<object, TaskCompletionSource<bool>> _initializationTasks = 
    new(DEFAULT_CONCURRENCY_LEVEL, 31);

Documentation Enhancement

Consider adding sequence diagrams or flowcharts to document the phase coordination between the three services, especially for future maintainers.

🎉 Excellent Work

This refactoring exemplifies:

  • Strategic thinking: Addressing architectural debt systematically
  • Risk management: Maintaining compatibility while improving structure
  • Performance awareness: Optimizing without sacrificing clarity
  • Standards compliance: Following TUnit's strict guidelines

Recommendation: ✅ APPROVE - This is a high-quality refactoring that significantly improves the codebase architecture.


@claude
Copy link
Contributor

claude bot commented Dec 2, 2025

Claude finished @thomhurst's task —— View job


✅ Code Review Complete

Reviewing the object lifecycle management and property injection refactoring. This is a significant change with +1011/-1209 lines across 17 files.

Review Tasks:

  • Read repository guidelines (CLAUDE.md)
  • Analyze the refactoring changes and architecture
  • Review deleted services to understand removed functionality
  • Examine new services for design patterns and quality
  • Check dual-mode implementation compliance
  • Evaluate performance implications
  • Look for potential bugs and security issues
  • Assess test coverage impact
  • Provide comprehensive feedback

✅ Overall Assessment: EXCELLENT REFACTORING

This is a well-executed consolidation that improves maintainability and follows solid architectural principles. The refactoring successfully addresses several architectural concerns while maintaining functionality.

🏗️ Architecture Improvements

Consolidation Benefits

  • Before: 5 fragmented services (PropertyInjectionService, DataSourceInitializer, PropertyInitializationOrchestrator, PropertyDataResolver, ObjectRegistrationService)
  • After: 3 cohesive services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Result: Cleaner separation of concerns with clear phase boundaries

Dependency Management

  • ✅ Excellent: Uses Lazy<T> to break circular dependencies without manual Initialize() calls
  • ✅ Clean: Eliminates the fragile two-phase initialization pattern
  • ✅ Type-Safe: Maintains compile-time safety while breaking cycles

Single Responsibility Principle

  • ObjectGraphDiscoveryService: Pure discovery, no modification
  • PropertyInjector: Pure injection, no lifecycle management
  • ObjectLifecycleService: Orchestrates phases but delegates specifics

🚀 Performance Considerations

✅ Positive Performance Impact

  • Eliminates duplicate object graph traversals across multiple services
  • Maintains object pooling for visited dictionaries (TUnit.Engine/Services/PropertyInjector.cs:22)
  • Preserves lazy initialization patterns for expensive operations
  • Uses ConcurrentDictionary for thread-safe caching

⚠️ Minor Performance Note

  • Lazy<T> introduces small overhead, but this is negligible compared to the elimination of duplicate traversals
  • Net performance should be improved due to reduced redundant work

🔒 Security & Robustness

✅ Security Compliance

  • Maintains proper [DynamicallyAccessedMembers] annotations for AOT compatibility
  • Preserves reflection safety patterns from TUnit guidelines
  • No sensitive data exposure in the refactored services

✅ Error Handling

  • Maintains proper null checking and argument validation
  • Preserves exception propagation patterns
  • Uses TaskCompletionSource<bool> for safe async coordination

🎯 Dual-Mode Implementation Compliance

✅ CRITICAL REQUIREMENT MET

This refactoring correctly maintains dual-mode support:

  • Source Generation Mode: Uses pre-compiled metadata via PropertyInjectionPlanBuilder
  • Reflection Mode: Falls back to runtime discovery
  • Integration Point: TUnit.Core/PropertyInjection/PropertyInjectionCache.cs:28 - PropertyInjectionPlanBuilder.Build(type)

The refactoring is service-layer only and doesn't change the dual-mode execution paths, which is architecturally sound.

📝 Code Quality

✅ Strengths

  • Modern C# Patterns: Proper use of ValueTask, file-scoped namespaces, collection expressions
  • Clear Documentation: Comprehensive XML docs explaining architectural decisions
  • Naming: Descriptive class and method names that convey intent
  • Consistent Style: Follows TUnit coding standards

✅ SOLID Principles

  • Single Responsibility: Each new service has a focused purpose
  • Open/Closed: Extensible design with clear interfaces
  • Liskov Substitution: Proper inheritance patterns
  • Interface Segregation: Focused interfaces like IObjectRegistry
  • Dependency Inversion: Uses abstractions and dependency injection

🧪 Test Coverage Impact

⚠️ Recommendation: Update Tests

While the refactoring maintains functionality, consider:

  • Unit tests for new services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Integration tests to verify the phase coordination works correctly
  • Performance benchmarks to validate the optimization claims

🔍 Minor Suggestions

Code Organization

// TUnit.Engine/Services/ObjectLifecycleService.cs:24
// Consider extracting this constant for maintainability
private const int DEFAULT_CONCURRENCY_LEVEL = Environment.ProcessorCount;
private readonly ConcurrentDictionary<object, TaskCompletionSource<bool>> _initializationTasks = 
    new(DEFAULT_CONCURRENCY_LEVEL, 31);

Documentation Enhancement

Consider adding sequence diagrams or flowcharts to document the phase coordination between the three services, especially for future maintainers.

🎉 Excellent Work

This refactoring exemplifies:

  • Strategic thinking: Addressing architectural debt systematically
  • Risk management: Maintaining compatibility while improving structure
  • Performance awareness: Optimizing without sacrificing clarity
  • Standards compliance: Following TUnit's strict guidelines

Recommendation: ✅ APPROVE - This is a high-quality refactoring that significantly improves the codebase architecture.


@claude
Copy link
Contributor

claude bot commented Dec 2, 2025

Claude finished @thomhurst's task —— View job


Claude Code is reviewing the refactoring

Code Review Tasks:

  • Read repository guidelines (CLAUDE.md)
  • Analyze deleted files to understand removed functionality
  • Review new files for architecture and design patterns
  • Examine modified files for integration points
  • Check for dual-mode implementation compliance
  • Evaluate performance implications
  • Look for potential bugs and security issues
  • Assess test coverage impact
  • Provide comprehensive feedback

Code Review Complete

Reviewing the object lifecycle management and property injection refactoring. This is a significant change with 1003 additions and 1206 deletions across 15 files.


✅ Overall Assessment: EXCELLENT REFACTORING

This is a well-executed consolidation that improves maintainability and follows solid architectural principles. The refactoring successfully addresses several architectural concerns while maintaining functionality.

🏗️ Architecture Improvements

Consolidation Benefits

  • Before: 5 fragmented services (PropertyInjectionService, DataSourceInitializer, PropertyInitializationOrchestrator, PropertyDataResolver, ObjectRegistrationService)
  • After: 3 cohesive services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Result: Cleaner separation of concerns with clear phase boundaries

Dependency Management

  • ✅ Excellent: Uses Lazy<T> to break circular dependencies without manual Initialize() calls
  • ✅ Clean: Eliminates the fragile two-phase initialization pattern
  • ✅ Type-Safe: Maintains compile-time safety while breaking cycles

Single Responsibility Principle

  • ObjectGraphDiscoveryService: Pure discovery, no modification
  • PropertyInjector: Pure injection, no lifecycle management
  • ObjectLifecycleService: Orchestrates phases but delegates specifics

🚀 Performance Considerations

✅ Positive Performance Impact

  • Eliminates duplicate object graph traversals across multiple services
  • Maintains object pooling for visited dictionaries (TUnit.Engine/Services/PropertyInjector.cs:22)
  • Preserves lazy initialization patterns for expensive operations
  • Uses ConcurrentDictionary for thread-safe caching

⚠️ Minor Performance Note

  • Lazy<T> introduces small overhead, but this is negligible compared to the elimination of duplicate traversals
  • Net performance should be improved due to reduced redundant work

🔒 Security & Robustness

✅ Security Compliance

  • Maintains proper [DynamicallyAccessedMembers] annotations for AOT compatibility
  • Preserves reflection safety patterns from TUnit guidelines
  • No sensitive data exposure in the refactored services

✅ Error Handling

  • Maintains proper null checking and argument validation
  • Preserves exception propagation patterns
  • Uses TaskCompletionSource<bool> for safe async coordination

🎯 Dual-Mode Implementation Compliance

✅ CRITICAL REQUIREMENT MET

This refactoring correctly maintains dual-mode support:

  • Source Generation Mode: Uses pre-compiled metadata via PropertyInjectionPlanBuilder
  • Reflection Mode: Falls back to runtime discovery
  • Integration Point: TUnit.Core/PropertyInjection/PropertyInjectionCache.cs:28 - PropertyInjectionPlanBuilder.Build(type)

The refactoring is service-layer only and doesn't change the dual-mode execution paths, which is architecturally sound.

📝 Code Quality

✅ Strengths

  • Modern C# Patterns: Proper use of ValueTask, file-scoped namespaces, collection expressions
  • Clear Documentation: Comprehensive XML docs explaining architectural decisions
  • Naming: Descriptive class and method names that convey intent
  • Consistent Style: Follows TUnit coding standards

✅ SOLID Principles

  • Single Responsibility: Each new service has a focused purpose
  • Open/Closed: Extensible design with clear interfaces
  • Liskov Substitution: Proper inheritance patterns
  • Interface Segregation: Focused interfaces like IObjectRegistry
  • Dependency Inversion: Uses abstractions and dependency injection

🧪 Test Coverage Impact

⚠️ Recommendation: Update Tests

While the refactoring maintains functionality, consider:

  • Unit tests for new services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Integration tests to verify the phase coordination works correctly
  • Performance benchmarks to validate the optimization claims

🔍 Minor Suggestions

Code Organization

// TUnit.Engine/Services/ObjectLifecycleService.cs:24
// Consider extracting this constant for maintainability
private const int DEFAULT_CONCURRENCY_LEVEL = Environment.ProcessorCount;
private readonly ConcurrentDictionary<object, TaskCompletionSource<bool>> _initializationTasks = 
    new(DEFAULT_CONCURRENCY_LEVEL, 31);

Documentation Enhancement

Consider adding sequence diagrams or flowcharts to document the phase coordination between the three services, especially for future maintainers.

🎉 Excellent Work

This refactoring exemplifies:

  • Strategic thinking: Addressing architectural debt systematically
  • Risk management: Maintaining compatibility while improving structure
  • Performance awareness: Optimizing without sacrificing clarity
  • Standards compliance: Following TUnit's strict guidelines

Recommendation: ✅ APPROVE - This is a high-quality refactoring that significantly improves the codebase architecture.


@claude
Copy link
Contributor

claude bot commented Dec 2, 2025

Claude finished @thomhurst's task —— View job


Claude Code is reviewing the refactoring

Code Review Tasks:

  • Read repository guidelines (CLAUDE.md)
  • Analyze deleted files to understand removed functionality
  • Review new files for architecture and design patterns
  • Examine modified files for integration points
  • Check for dual-mode implementation compliance
  • Evaluate performance implications
  • Look for potential bugs and security issues
  • Assess test coverage impact
  • Provide comprehensive feedback

Code Review Complete

Reviewing the object lifecycle management and property injection refactoring. This is a significant change with 1003 additions and 1206 deletions across 15 files.


✅ Overall Assessment: EXCELLENT REFACTORING

This is a well-executed consolidation that improves maintainability and follows solid architectural principles. The refactoring successfully addresses several architectural concerns while maintaining functionality.

🏗️ Architecture Improvements

Consolidation Benefits

  • Before: 5 fragmented services (PropertyInjectionService, DataSourceInitializer, PropertyInitializationOrchestrator, PropertyDataResolver, ObjectRegistrationService)
  • After: 3 cohesive services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Result: Cleaner separation of concerns with clear phase boundaries

Dependency Management

  • ✅ Excellent: Uses Lazy<T> to break circular dependencies without manual Initialize() calls
  • ✅ Clean: Eliminates the fragile two-phase initialization pattern
  • ✅ Type-Safe: Maintains compile-time safety while breaking cycles

Single Responsibility Principle

  • ObjectGraphDiscoveryService: Pure discovery, no modification
  • PropertyInjector: Pure injection, no lifecycle management
  • ObjectLifecycleService: Orchestrates phases but delegates specifics

🚀 Performance Considerations

✅ Positive Performance Impact

  • Eliminates duplicate object graph traversals across multiple services
  • Maintains object pooling for visited dictionaries (TUnit.Engine/Services/PropertyInjector.cs:22)
  • Preserves lazy initialization patterns for expensive operations
  • Uses ConcurrentDictionary for thread-safe caching

⚠️ Minor Performance Note

  • Lazy<T> introduces small overhead, but this is negligible compared to the elimination of duplicate traversals
  • Net performance should be improved due to reduced redundant work

🔒 Security & Robustness

✅ Security Compliance

  • Maintains proper [DynamicallyAccessedMembers] annotations for AOT compatibility
  • Preserves reflection safety patterns from TUnit guidelines
  • No sensitive data exposure in the refactored services

✅ Error Handling

  • Maintains proper null checking and argument validation
  • Preserves exception propagation patterns
  • Uses TaskCompletionSource<bool> for safe async coordination

🎯 Dual-Mode Implementation Compliance

✅ CRITICAL REQUIREMENT MET

This refactoring correctly maintains dual-mode support:

  • Source Generation Mode: Uses pre-compiled metadata via PropertyInjectionPlanBuilder
  • Reflection Mode: Falls back to runtime discovery
  • Integration Point: TUnit.Core/PropertyInjection/PropertyInjectionCache.cs:28 - PropertyInjectionPlanBuilder.Build(type)

The refactoring is service-layer only and doesn't change the dual-mode execution paths, which is architecturally sound.

📝 Code Quality

✅ Strengths

  • Modern C# Patterns: Proper use of ValueTask, file-scoped namespaces, collection expressions
  • Clear Documentation: Comprehensive XML docs explaining architectural decisions
  • Naming: Descriptive class and method names that convey intent
  • Consistent Style: Follows TUnit coding standards

✅ SOLID Principles

  • Single Responsibility: Each new service has a focused purpose
  • Open/Closed: Extensible design with clear interfaces
  • Liskov Substitution: Proper inheritance patterns
  • Interface Segregation: Focused interfaces like IObjectRegistry
  • Dependency Inversion: Uses abstractions and dependency injection

🧪 Test Coverage Impact

⚠️ Recommendation: Update Tests

While the refactoring maintains functionality, consider:

  • Unit tests for new services (ObjectLifecycleService, PropertyInjector, ObjectGraphDiscoveryService)
  • Integration tests to verify the phase coordination works correctly
  • Performance benchmarks to validate the optimization claims

🔍 Minor Suggestions

Code Organization

// TUnit.Engine/Services/ObjectLifecycleService.cs:24
// Consider extracting this constant for maintainability
private const int DEFAULT_CONCURRENCY_LEVEL = Environment.ProcessorCount;
private readonly ConcurrentDictionary<object, TaskCompletionSource<bool>> _initializationTasks = 
    new(DEFAULT_CONCURRENCY_LEVEL, 31);

Documentation Enhancement

Consider adding sequence diagrams or flowcharts to document the phase coordination between the three services, especially for future maintainers.

🎉 Excellent Work

This refactoring exemplifies:

  • Strategic thinking: Addressing architectural debt systematically
  • Risk management: Maintaining compatibility while improving structure
  • Performance awareness: Optimizing without sacrificing clarity
  • Standards compliance: Following TUnit's strict guidelines

Recommendation: ✅ APPROVE - This is a high-quality refactoring that significantly improves the codebase architecture.


This was referenced Dec 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Too many calls to InitializeAsync

2 participants