Remote log callback delivers no lines on the component-split branch (#1622)
Nobody has claimed this yet.
- Dominant language
- Cuda
- Stars
- 1k
- Forks
- 233
- Avg merge
- 4d 4h
- Merged PRs (30d)
- 95
Description
Description
On #1622 (feat/split-routing-lp-libs), CpuOnlyWithServerTest.log_callback_remote fails:
Expected remote solve to deliver log lines; got 0 calls
cpp/tests/linear_programming/c_api_tests/c_api_tests.cpp:797: Failure
The remote solve itself succeeds — CpuOnlyWithServerTest.lp_solve and .mip_solve pass, returning Optimal with the correct objective. Only the streamed log lines never reach the callback registered through cuOptSetLogCallback.
Not caused by the cuopt_base removal
I hit this while removing cuopt_base from that branch and checked before attributing it. Rebuilding the branch with cuopt_base restored (cpp/CMakeLists.txt and cpp/src/CMakeLists.txt from the pre-removal commit) reproduces the failure identically, so it predates that change.
It is specific to the component split: the same test passes on split/4-cuopt-client-library, which carries a monolithic libcuopt.so and is otherwise up to date with main.
Where to look
cuopt_mathopt no longer hard-links gRPC on that branch. It holds nullable callback slots that libcuopt_grpc.so's ELF constructor fills via register_remote_solvers(), and the log callback has to cross the same boundary. Two candidates:
- the log callback is registered on one side of that boundary and read on the other, so the streaming path sees a null or default-constructed callback
- per-component loggers (#1778) mean the log lines the gRPC client streams are written to a different logger instance than the one the C API callback is attached to
The second is worth checking first, since #1778 gave each component library its own logger and the remote log path spans cuopt_mathopt and cuopt_grpc.
Reproduce
./build.sh libcuopt
cd cpp/build
./tests/linear_programming/C_API_TEST --gtest_filter='CpuOnlyWithServerTest.log_callback_remote'
Note that the fixture forks a cuopt_grpc_server on port 18500. A leaked server from an earlier run will make lp_solve and mip_solve fail too, with Error solving problem: 6, which is a separate and purely local artifact — check ss -ltnp | grep 18500 before drawing conclusions.
Related: #1622, #1778, #1510.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Run ./build.sh libcuopt, then execute cpp/build/tests/linear_programming/C_API_TEST with the CpuOnlyWithServerTest.log_callback_remote filter, checking port 18500 first. Trace callback registration across cuopt_mathopt and cuopt_grpc, including the per-component logger instances from #1778. Done means the remote solve still succeeds and streamed log lines reach the callback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, cpp, grpc
- Domain
- backend-api-design, distributed-systems, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100