Add C# bindings and websocket client

[georgi]

Summary

• add script to export pydantic types to C#
• generate MessagePack compatible C# models
• add simple WebSocket runner client in C#
• add project file and docs

Testing

• pytest -q

[claude]

Claude finished @georgi's task —— View job

---

Comprehensive PR Review

I've completed a thorough review of the C# bindings and WebSocket client implementation. Here's my detailed analysis:

Todo List:

• Read and analyze the Python export script (tools/export_csharp_types.py)
• Review generated C# types (csharp/Nodetool/Metadata/Types.cs)
• Analyze WebSocket client implementation (csharp/Nodetool/WebSocketRunnerClient.cs)
• Check project configuration (csharp/Nodetool/Nodetool.csproj)
• Review documentation (csharp/README.md)
• Assess security implications
• Evaluate test coverage and recommendations
• Provide comprehensive feedback and recommendations

---

🚨 Critical Issues

1. Security Vulnerability in WebSocketRunnerClient.cs:64

{"auth_token", "local_token"}

Issue: Hardcoded authentication token exposes a significant security risk. This could lead to unauthorized access in production environments.

Recommendation:

• Make auth token configurable via constructor parameter
• Consider implementing proper authentication mechanisms
• Add validation for token format/source

2. Type Safety Issues in Export Script

tools/export_csharp_types.py:17,23:

return "object"  # Fallback for unsupported types

Issue: Many Python types are being mapped to generic object type, losing type safety and potentially causing runtime errors.

Specific examples from generated code:

• public object type { get; set; } appears frequently
• public object asset_id { get; set; } should likely be string?
• public object data { get; set; } loses all type information

⚠️ Major Issues

3. Resource Management in WebSocketRunnerClient

WebSocketRunnerClient.cs:24,38:

private ClientWebSocket _socket = new ClientWebSocket();
// Later...
_socket = new ClientWebSocket(); // Previous socket not disposed

Issue: Potential memory leak - previous WebSocket instances aren't properly disposed when reconnecting.

Recommendation:

if (_socket != null)
{
    _socket.Dispose();
}
_socket = new ClientWebSocket();

4. Message Buffer Size Limitation

WebSocketRunnerClient.cs:81:

var buffer = new byte[1024 * 32]; // Fixed 32KB buffer

Issue: Fixed buffer size may cause message truncation for large payloads, leading to deserialization failures.

Recommendation: Implement dynamic buffer resizing or chunked message handling.

5. Exception Handling Gaps

WebSocketRunnerClient.cs:89:

var data = MessagePackSerializer.Deserialize<Dictionary<string, object>>(buffer.AsMemory(0, result.Count));

Issue: No exception handling for malformed messages could crash the client.

Recommendation: Wrap in try-catch and implement error recovery.

🔧 Moderate Issues

6. Project Configuration

Nodetool.csproj:3: Uses .NET 6.0 which reaches end-of-life in November 2024.
Recommendation: Consider upgrading to .NET 8.0 (LTS) for better long-term support.

7. Type Mapping Incompleteness

export_csharp_types.py:8-38: The type mapping function has several gaps:

• No handling for datetime types (common in APIs)
• No support for generic constraints
• Union types with >1 non-None type default to object

✅ Positive Aspects

1. Clean Architecture: Well-structured separation between type generation and client implementation
2. MessagePack Integration: Proper use of MessagePack attributes for serialization
3. Async Pattern: Correct implementation of async/await patterns in WebSocket client
4. State Management: Clear state tracking with RunnerState enum
5. Documentation: Good README explaining usage and regeneration process

📝 Recommendations

Immediate Actions:

1. Fix security issue: Remove hardcoded auth token
2. Improve resource management: Fix WebSocket disposal
3. Add error handling: Wrap deserialization calls
4. Enhance type mapping: Reduce reliance on object type

Future Improvements:

1. Add unit tests: No tests currently exist for C# components
2. Implement logging: Add structured logging for debugging
3. Add validation: Validate message formats and required fields
4. Consider cancellation: Improve cancellation token usage throughout
5. Add reconnection logic: Handle network failures gracefully

Suggested Type Mapping Improvements:

# In py_type_to_cs function, add:
if py_t is datetime or py_t is date:
    return "DateTime"
# Better handling of Optional types
if origin is Union and len(args) == 2 and type(None) in args:
    non_none = [a for a in args if a is not type(None)][0]
    return py_type_to_cs(non_none) + "?"

🧪 Test Coverage Recommendations

1. Python Export Script Tests:

   • Test type mapping edge cases
   • Verify generated C# syntax validity
   • Test with complex nested types

2. WebSocket Client Tests:

   • Connection handling scenarios
   • Message serialization/deserialization
   • Error conditions and recovery
   • Cancellation scenarios

3. Integration Tests:

   • End-to-end workflow execution
   • MessagePack compatibility verification

---

Overall Assessment: This is a solid foundation for C# interoperability, but requires security fixes and improved error handling before production use. The generated types approach is elegant, though the type mapping needs refinement for better type safety.