The Solution class suffers from inconsistent attribute guards and misleading error reporting. Specifically, LP-only methods fail to consistently reject MILP inputs, and those that do provide incorrect method names in their exception messages.
Evidence & Points:
- Misleading Error Messages via
__name__:
Methods like get_dual_solution pass __name__ (the module name) instead of the method name to raise_if_milp_solution.
- Actual Error:
Attribute cuopt.linear_programming.solution is not supported...
- Expected Error:
Attribute get_dual_solution is not supported...
- Missing MILP Guards for LP-only Accessors:
get_reduced_cost() and get_pdlp_warm_start_data() lack raise_if_milp_solution guards. This allows MILP users to retrieve None or meaningless data silently, contradicting the documentation which states these are "Applicable only to LP."
- Unnecessary Object Instantiation:
PDLPWarmStartData is instantiated regardless of the problem_category. For MILP/IP problems, this results in a "ghost" object filled with None values, leading to ambiguous API semantics.
- Fragile Enum Mapping in
_set_termination_status:
The logic assumes anything not LP is MILP. If problem_category is ever expanded or corrupted, this will trigger unhandled ValueError during Enum conversion without proper defensive checks.
Impact:
- Broken Developer Experience (DX) due to confusing error messages.
- Risk of silent data corruption in MILP pipelines.
- API behavior that directly contradicts the provided docstrings.
The
Solutionclass suffers from inconsistent attribute guards and misleading error reporting. Specifically, LP-only methods fail to consistently reject MILP inputs, and those that do provide incorrect method names in their exception messages.Evidence & Points:
__name__:Methods like
get_dual_solutionpass__name__(the module name) instead of the method name toraise_if_milp_solution.Attribute cuopt.linear_programming.solution is not supported...Attribute get_dual_solution is not supported...get_reduced_cost()andget_pdlp_warm_start_data()lackraise_if_milp_solutionguards. This allows MILP users to retrieveNoneor meaningless data silently, contradicting the documentation which states these are "Applicable only to LP."PDLPWarmStartDatais instantiated regardless of theproblem_category. For MILP/IP problems, this results in a "ghost" object filled withNonevalues, leading to ambiguous API semantics._set_termination_status:The logic assumes anything not
LPisMILP. Ifproblem_categoryis ever expanded or corrupted, this will trigger unhandledValueErrorduring Enum conversion without proper defensive checks.Impact: