Add type validation for signal handler and server shutdown statements

[coderabbitai]

Description

The type checker currently lacks proper validation for signal handler registration and server shutdown statements in src/typechecker/mod.rs (lines 1356-1381).

Missing Validations

RegisterSignalHandlerStatement

• Should validate signal_type string against supported signal types (SIGINT, SIGTERM, etc.)
• Should ensure handler_name refers to a defined handler with correct signature

StopAcceptingConnectionsStatement & CloseServerStatement

• Should validate that server expression resolves to a Server type
• Should error if server type is incompatible (unless Unknown/Error for graceful degradation)

Current State

All three statement types currently accept any input without validation:

// TODO: Add type checking for signal handler registration
// For now, just accept any signal type and handler name

// TODO: Add type checking for server expression  
// For now, just accept any type

Suggested Implementation

• Add infer_expression_type(server) calls and type compatibility checks
• Validate signal type strings against known signal constants
• Ensure handler names resolve to callable actions with appropriate signatures

Impact

• Improved compile-time error detection
• Better developer experience with clear type mismatch messages
• Prevents runtime errors from invalid signal/server references

References

• PR: Implements Web Server & Hardens WFLHASH Security #169 (comment)
• Comment: Implements Web Server & Hardens WFLHASH Security #169 (comment)
• Requested by: @logbie

[logbie]

@claude investigate and report your findings as well as a recommendation

[claude]

Claude finished @logbie's task —— View job

---

Investigation Results: Type validation for signal handler and server shutdown statements

Todo List:

• Read and analyze current typechecker code (lines 1356-1381)
• Examine AST definitions for the relevant statements
• Research existing signal and server type definitions in codebase
• Analyze similar validation patterns already implemented
• Provide detailed findings and recommendations

---

🔍 Current State Analysis

I've thoroughly investigated the typechecker code and related components. Here's what I found:

Missing Type Validations in src/typechecker/mod.rs:1356-1381

All three statement types currently have empty implementations with TODO comments:

1. RegisterSignalHandlerStatement - No validation of signal_type string or handler_name
2. StopAcceptingConnectionsStatement - No validation of server expression type
3. CloseServerStatement - No validation of server expression type

AST Structure Analysis

From src/parser/ast.rs:406-421:

• RegisterSignalHandlerStatement: signal_type: String, handler_name: String
• StopAcceptingConnectionsStatement: server: Expression
• CloseServerStatement: server: Expression

Existing Validation Patterns

The typechecker follows consistent validation patterns I found in other statements:

// Example from HttpGetStatement (lines 323-332)
let url_type = self.infer_expression_type(url);
if url_type != Type::Text && url_type != Type::Unknown && url_type != Type::Error {
    self.type_error(
        "URL must be a text string".to_string(),
        Some(Type::Text),
        Some(url_type),
        *_line,
        *_column,
    );
}

📋 Findings & Recommendations

1. Signal Handler Validation

Current Issues:

• No validation of signal type strings (SIGINT, SIGTERM, etc.)
• No validation that handler_name refers to a defined action

Evidence from TestPrograms:

• Only SIGINT and SIGTERM are used in existing WFL programs
• Handler names like graceful_shutdown_handler must be defined actions

Recommended Implementation:

Statement::RegisterSignalHandlerStatement {
    signal_type,
    handler_name,
    line,
    column,
} => {
    // Validate signal type against known signals
    let valid_signals = vec!["SIGINT", "SIGTERM"];
    if !valid_signals.contains(&signal_type.as_str()) {
        self.type_error(
            format!("Unsupported signal type: {signal_type}"),
            None,
            None,
            *line,
            *column,
        );
    }
    
    // Validate handler name refers to defined action
    if !self.analyzer.get_symbol(handler_name).is_some() {
        self.type_error(
            format!("Undefined signal handler: {handler_name}"),
            None,
            None,
            *line,
            *column,
        );
    }
}

2. Server Statement Validation

Current Issues:

• No type checking on server expressions
• Should validate server expressions resolve to appropriate server types

Evidence from codebase:

• WflWebServer struct exists in interpreter (src/interpreter/mod.rs:78)
• Servers stored in web_servers HashMap as HashMap<String, WflWebServer>
• Server variables appear to be represented as Text type (src/analyzer/mod.rs:1310)

Recommended Implementation:

Statement::StopAcceptingConnectionsStatement {
    server,
    line,
    column,
} => {
    let server_type = self.infer_expression_type(server);
    // Accept Text (server names), Unknown (during inference), or Error (graceful degradation)
    if server_type != Type::Text && server_type != Type::Unknown && server_type != Type::Error {
        self.type_error(
            "Server expression must resolve to a server name (Text)".to_string(),
            Some(Type::Text),
            Some(server_type),
            *line,
            *column,
        );
    }
}

Statement::CloseServerStatement {
    server,
    line,
    column,
} => {
    let server_type = self.infer_expression_type(server);
    if server_type != Type::Text && server_type != Type::Unknown && server_type != Type::Error {
        self.type_error(
            "Server expression must resolve to a server name (Text)".to_string(),
            Some(Type::Text),
            Some(server_type),
            *line,
            *column,
        );
    }
}

💡 Impact Assessment

Benefits of Implementation:

• ✅ Compile-time error detection - Catch invalid signal types and undefined handlers early
• ✅ Better developer experience - Clear error messages for type mismatches
• ✅ Runtime safety - Prevent crashes from invalid signal/server references
• ✅ Consistency - Follows existing typechecker patterns in the codebase

Risk Assessment:

• 🟡 Low risk - Implementation follows established patterns
• 🟡 Backward compatible - Only adds validation, doesn't change language syntax
• 🟡 Graceful degradation - Allows Unknown/Error types to maintain flexibility

📝 Next Steps

The implementation should be straightforward by following the established validation patterns found throughout src/typechecker/mod.rs. The key is to:

1. Use self.infer_expression_type() for server expressions
2. Check against valid signal type constants for signal handlers
3. Validate handler names exist in the symbol table
4. Follow the graceful degradation pattern (allow Unknown/Error types)
5. Use consistent error reporting via self.type_error()

---