Description
#1803 split warm-start handling into three helpers but added no test coverage for the conversion paths themselves. CodeRabbit flagged this during review; it needs a GPU fixture with a populated warm start, so it was left out of that PR rather than expanding its scope.
Paths needing coverage:
- host-view (Cython spans) → CPU target
- host data → GPU target (H2D via
convert_to_gpu_warmstart)
- device data → CPU target (D2H via
convert_to_cpu_warmstart)
The third is the one worth prioritising: it was silently dropped in an early revision of #1803 and only caught by review. The failure mode is a lost warm start with no error — a caller passing handle == nullptr from a context that does have a device (cython_solve.cu:181) simply gets degraded results.
Related: #1801, #1802, #1803, #1804.
Description
#1803 split warm-start handling into three helpers but added no test coverage for the conversion paths themselves. CodeRabbit flagged this during review; it needs a GPU fixture with a populated warm start, so it was left out of that PR rather than expanding its scope.
Paths needing coverage:
convert_to_gpu_warmstart)convert_to_cpu_warmstart)The third is the one worth prioritising: it was silently dropped in an early revision of #1803 and only caught by review. The failure mode is a lost warm start with no error — a caller passing
handle == nullptrfrom a context that does have a device (cython_solve.cu:181) simply gets degraded results.Related: #1801, #1802, #1803, #1804.