This transformation is recognized by Gurobi/Cplex/Xpress(?) only when f is a VectorOfVariables. They can't handle general affine expressions. That creates a tricky situation because we don't have a way to indicate this restriction in MOI afaik, so I'm questioning if bridges are the right place for this transformation to happen. Maybe the solvers need to support VectorOfVariables-in-SecondOrderCone and then let a bridge handle only the transformation from VectorAffineFunction-in-SecondOrderCone to VectorOfVariables-in-SecondOrderCone.

They also support x^T Q x +q^T x <= b apparently: http://www.gurobi.com/documentation/8.0/refman/constraints.html#subsubsection:QuadraticConstraints
so if it is a VectorAffineFunction in SOC, it will be transformed into x^T Q x +q^T x <= b with Q PSD an Gurobi will also support it, won't it ?

This bridge does not generate a constraint of the form x^T Q x +q^T x <= b where Q is PSD (there's one negative eigenvalue).

Indeed, good point. This bridge could create a vector of variables and constraint them to be equal to the affexpr and then use these auxiliary variables to create the quadratic function. This would not only make sense for Gurobi as taking the square of complicated affine expression may not result in a very simple quadratic function so it might be the right idea anyway.
Would that work ?

That works for Gurobi et al, but I think there's a larger design issue. Ipopt supports convex and non-convex quadratic constraints but not SOC constraints (there's no special detection for x^T x <= t^2). It this bridge is applied, Ipopt will treat the constraint as a nonconvex quadratic constraint without any guarantees of global optimality. Unless there are additional properties of this transformation that imply that a KKT point must be globally optimal (even though the problem is nonconvex), this means that the user could write down a convex problem using SOC and get a bad answer back from Ipopt.

same for CPLEX: https://www.ibm.com/support/knowledgecenter/en/SS9UKU_12.4.0/com.ibm.cplex.zos.help/UsrMan/topics/cont_optim/qcp/18_eg_SOCP.html

We discussed about this issue with @mlubin and @ccoffrin. The approach would be to define this bridge in MOI but not add it in full_bridge_optimizer so that the user would have to add it manually with JuMP.add_bridge. By choosing which bridge to add, it would either allow VectorOfVariables-in-SOC or VectorAffineFunction-in-SOC to add so he is responsible to add the one with which the optimizer works.
IMO the optimizer could also simply apply the bridge automatically by itself with a SingleBridgeOptimizer. Choosing to build the API on top of quadratic functions instead of SOC constraints was a bad design choice and this is the reason this bridge seems weird because it destroys a structure that the optimizers try to recover afterwards.

Since the three solvers support SOC´s as special quadratic constraints, the bridge could be very useful. Given Ipopt's problem, we could have it non-default, and add a note about the issue.

@joaquimg IMO the right solution for this is for Gurobi/Xpress/CPLEX to explicitly support VoV/VAF-in-SOC in their interfaces. We have no other way to know if a solver secretly supports SOC through quadratic constraints.

this means that the user could write down a convex problem using SOC and get a bad answer back from Ipopt.

Regarding this point. As I understand the theory, it does not matter in what form a convex constraint is given to a IPM solver. The KKT convergence guarantees will be the same; so I don't think this a major issue for the case of targeting NLP solvers.