Yes, the trace depth is limiting the number of recursions. The recommendation to use iterative instead of recursive algorithms reduces the recursion amount to only one or mostly two trace levels. (Normally two if the closest hit program shoots a visibility ray for direct lighting.)
Most path tracers are written as iterative algorithms and continue in only one direction on a transparent surface (reflection or transmission) by sampling its probability in a progressive rendering algorithm.
If you are not rendering progressively but need a final frame in one launch that would require to store all possible ray directions during the surface sampling. That can be done with a ray stack in the ray generation program and additional secondary ray information at the per ray data (PRD) payload.
Basically implement a unidirectional path tracer and whenever there can be reflection and transmission events, handle one of the new sampled directions like the usual path continuation and store the secondary ray, path length, and material information on the PRD as well and push them onto the ray stack in the ray generation program and handle it later.
That would require as many rays in the ray stack as your maximum recursion depth.
This algorithm is heavy on the required memory bandwidth!
Rough outline of that as pseudo algorithm:
initialize ray stack to be empty;
generate primary ray;
push primary ray onto ray stack;
while (ray stack is not empty)
pop ray segment information from ray stack;
init PRD with current ray segment;
while (current path length <= max path length)
optixTrace(current ray segment in PRD);
if (ray split event)
push secondary split ray from PRD onto stack;
accumulate returned radiance;
if (terminate path event)
adjust path throughput;
++current path length;
store radiance into output buffer;
While not written with OptiX 7 but OptiX 5, the OptiX Introduction examples contain a progressive unidirectional path tracer which handles glass just fine, you would just need to increase the maximum path length.