Ignored lazy constraints lead to wrong solution -- another case

Hello,

I seem to have a problem similar to posts such as these:

https://support.gurobi.com/hc/en-us/community/posts/360078071312-Ignored-lazy-constraint-leads-to-wrong-solution

Since that post is closed, I am opening another issue.

I have a minimal reproducable example. https://godbolt.org/z/M1Eecsa7j is an input text file. This has details such as number of columns, Ncol of 28, Objective is to minimize, Variable bounds and other details are provided. 

Initially, an LP is formed with just the variables and bounds with no constraints. Then, constraints are added to this LP. 

Rows “Ineqtype” indicate the constraints. An ineqtype of 0 means that this was generated by running my separation routine given the current LP solution. The first inequality, Inequality 1, for instance, has 7 variables, index 0 has coefficient 3.333333, …, variable 6 has coefficient 3.333333. The sense of the constraint is ‘G’ and the rhs is 8.733333. There are a total of 92 such inequalities I discover.

Then, I convert the problem into an integer program and submit the problem to Gurobi to solve.

The inequalities 93 through 101 are discovered in the lazy cut callback (they are denoted as ineqtype 2) and are violated by the queried XBar inside of the lazy cut. One will notice that Inequalities 93 through 99 are repeatedly generated by Gurobi. Same with inequality 100 and 101.

Troublingly, inside of the lazy callback, I check each time to see if the queried XBar violates the next lazy cut I intend to add. Each time, this test succeeds. So, no feasible solution should be discovered. Yet, Gurobi deems that it has found the optimal solution and terminates.

The code to parse the input text file and reproduce the above issue is here: 

https://godbolt.org/z/dd4hx47c8

Thanks