Fix panic on invalid OSPF area-type configuration

[Copilot]

The OSPF daemon panics when an invalid area-type value is provided (e.g., stub-nssa-area), causing cascade thread failures. The validation callback calls .unwrap() on AreaType::try_from_yang(), which returns None for invalid values.

Changes

• Validation callback (line 1670-1674): Replace .unwrap() with .ok_or_else() to return descriptive error listing valid options
• Modify apply callback (line 515-516): Replace .unwrap() with .expect() since validation guarantees validity

// Before
let area_type = AreaType::try_from_yang(&area_type).unwrap();

// After (validation)
let area_type = AreaType::try_from_yang(&area_type)
    .ok_or_else(|| format!(
        "invalid area type '{}'. Valid options are: 'ietf-ospf:normal-area', 'ietf-ospf:stub-area', 'ietf-ospf:nssa-area'",
        area_type
    ))?;

Invalid values now return validation errors instead of crashing the daemon.

Original prompt

Fix panic when invalid area-type is provided in OSPF configuration

Problem Description

When an invalid area-type value (such as stub-nssa-area) is entered in the OSPF configuration, the system crashes with a panic instead of returning a proper validation error. This causes multiple threads to crash in a cascade failure.

Root Cause

The issue is in holo-ospf/src/northbound/configuration.rs at line 1668, where the code calls .unwrap() on the result of AreaType::try_from_yang():

let area_type = args.dnode.get_string();
let area_type = AreaType::try_from_yang(&area_type).unwrap(); // Panics on None!
if area_type == AreaType::Nssa {
    return Err("unsupported area type".to_string());
}

When an invalid area-type value is provided:

1. try_from_yang() returns None
2. .unwrap() panics
3. Multiple threads crash in cascade
4. The entire OSPF daemon crashes

Error Logs

thread 'tokio-runtime-worker' (976888) panicked at holo-ospf/src/northbound/configuration.rs:1668:65:
called `Option::unwrap()` on a `None` value

thread 'tokio-runtime-worker' (974520) panicked at /home/frr/holo/holo-northbound/src/configuration.rs:642:46:
called `Result::unwrap()` on an `Err` value: RecvError(())

thread 'tokio-runtime-worker' (974411) panicked at holo-daemon/src/northbound/core.rs:458:36:
called `Result::unwrap()` on an `Err` value: RecvError(())

thread 'main' (974376) panicked at holo-daemon/src/northbound/core.rs:464:26:
called `Result::unwrap()` on an `Err` value: JoinError::Panic(...)

thread 'tokio-runtime-worker' (974504) panicked at holo-daemon/src/northbound/client/grpc.rs:280:46:
called `Result::unwrap()` on an `Err` value: RecvError(())

Expected Behavior

The system should return a proper validation error message indicating that the area-type value is invalid, listing the valid options.

Valid area-type Values

According to the YANG schema (holo-yang/modules/ietf/ietf-ospf@2022-10-19.yang) and the implementation, the valid values are:

• ietf-ospf:normal-area
• ietf-ospf:stub-area
• ietf-ospf:nssa-area

Note: stub-nssa-area exists in the YANG schema as a base identity but is not a valid leaf value for configuration.

Solution

Replace the .unwrap() call with proper error handling that returns a descriptive validation error:

let area_type = args.dnode.get_string();
let area_type = AreaType::try_from_yang(&area_type)
    .ok_or_else(|| format!(
        "invalid area type '{}'. Valid options are: 'ietf-ospf:normal-area', 'ietf-ospf:stub-area', 'ietf-ospf:nssa-area'",
        area_type
    ))?;

if area_type == AreaType::Nssa {
    return Err("unsupported area type".to_string());
}

Files to Modify

• holo-ospf/src/northbound/configuration.rs - Line 1668 in the load_validation_callbacks() function

Testing

After the fix:

1. Input an invalid area-type value like stub-nssa-area
2. The system should return a validation error: "invalid area type 'stub-nssa-area'. Valid options are: 'ietf-ospf:normal-area', 'ietf-ospf:stub-area', 'ietf-ospf:nssa-area'"
3. The system should not crash
4. Other configuration commands should continue to work normally

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.