Follow-up: make WORK_LIMIT handling consistent in strong branching pseudo-costs

[coderabbitai]

Summary

There is a pre-existing inconsistency in cpp/src/branch_and_bound/pseudo_costs.cpp around how dual_status_t::WORK_LIMIT is handled in strong-branching and reliability-branching code paths.

Today, some merge/validation logic treats WORK_LIMIT as a usable Dual Simplex outcome, but the corresponding objective-computation paths do not consistently compute and propagate an objective for that status. That can lead to a WORK_LIMIT result being selected as a Dual Simplex contribution while still carrying a NaN objective, which then prevents the expected pseudo-cost update.

Why this matters

Strong branching and reliability branching rely on consistent status/objective handling to produce valid pseudo-cost updates and branch scoring. If WORK_LIMIT is considered a valid partial result, the code should compute and carry the corresponding objective everywhere that status is accepted.

Affected area

• cpp/src/branch_and_bound/pseudo_costs.cpp

Relevant logic includes:

• is_dual_simplex_done(...)
• strong branching result handling in strong_branch_helper(...)
• trial branching result handling in trial_branching(...)
• merge logic in merge_sb_result(...)

Requested follow-up

Make WORK_LIMIT handling consistent across all Dual Simplex strong-branching paths in cpp/src/branch_and_bound/pseudo_costs.cpp.

Specifically:

• If WORK_LIMIT is intended to be a usable Dual Simplex result, include it everywhere the code currently accepts other usable partial outcomes such as ITERATION_LIMIT and CUTOFF.
• Ensure the objective value is computed and propagated for WORK_LIMIT in the same places where that status is considered mergeable/consumable.
• Verify that the resulting pseudo-cost update paths no longer silently skip valid WORK_LIMIT outcomes due to NaN objectives.

Acceptance criteria

• WORK_LIMIT is handled consistently in status validation, objective computation, and merge logic for the affected strong-branching code paths.
• No path can merge/select a Dual Simplex WORK_LIMIT result while leaving its objective as NaN.
• The follow-up is handled separately from PR Refactor: mathematical_optimization namespace #1446 because this is a pre-existing issue.

Backlinks

• Reported from PR Refactor: mathematical_optimization namespace #1446: Refactor: mathematical_optimization namespace #1446
• Review discussion: Refactor: mathematical_optimization namespace #1446 (comment)

Requested by @mlubin.

[github-actions]

🔔 Hi @anandhkb @kaatish, this issue has had no activity for 21 days. Please update or let us know if it can be closed. Thank you!

If this is an "epic" issue, then please add the "epic" label to this issue.
If it is a PR and not ready for review, then please convert this to draft.
If you just want to switch off this notification, then use the "skip inactivity reminder" label.