Using DPP, on model.update https://github.com/osqp/osqp-python/blob/v0.6.3/src/osqp/interface.py#L39 if l is unchanged and u has changed we call update_upper_bound but as (what I think is) a consequence of scaling (since when I set it to 0 the error disappears) in doing so at the C level the check that all(l_cached < u_updated) does not hold.
File /opt/homebrew/Caskroom/miniforge/base/envs/hack/lib/python3.10/site-packages/cvxpy/reductions/solvers/qp_solvers/osqp_qpif.py:95, in OSQP.solve_via_data(self, data, warm_start, verbose, solver_opts, solver_cache)
92 factorizing = True
94 if new_args:
---> 95 solver.update(**new_args)
96 # Map OSQP statuses back to CVXPY statuses
97 status = self.STATUS_MAP.get(results.info.status_val, s.SOLVER_ERROR)
File /opt/homebrew/Caskroom/miniforge/base/envs/hack/lib/python3.10/site-packages/osqp/interface.py:92, in OSQP.update(self, q, l, u, Px, Px_idx, Ax, Ax_idx)
90 # update upper bound
91 if u is not None and l is None:
---> 92 self._model.update_upper_bound(u)
94 # update bounds
95 if l is not None and u is not None:
ValueError: Upper bound update error!
Using DPP, on model.update https://github.com/osqp/osqp-python/blob/v0.6.3/src/osqp/interface.py#L39 if l is unchanged and u has changed we call update_upper_bound but as (what I think is) a consequence of scaling (since when I set it to 0 the error disappears) in doing so at the C level the check that all(l_cached < u_updated) does not hold.
Raising it closer to the metal first ... the corresponding issue on the CVXPY front https://github.com/cvxpy/cvxpy/issues/2235