})
	c.queue = controllers.NewQueue("repair pods",
		controllers.WithReconciler(c.Reconcile),
		controllers.WithMaxAttempts(5))
	c.pods.AddEventHandler(controllers.ObjectHandler(c.queue.AddObject))

	return c, nil
}

func (c *Controller) Run(stop <-chan struct{}) {
	kube.WaitForCacheSync("repair controller", stop, c.pods.HasSynced)
	c.queue.Run(stop)
	c.pods.ShutdownHandlers()
}

			c, err := NewRepairController(tt.client, tt.config)
			assert.NoError(t, err)
			t.Cleanup(func() {
				assert.NoError(t, c.queue.WaitForClose(time.Second))
			})
			stop := test.NewStop(t)
			tt.client.RunAndWait(stop)
			go c.Run(stop)
			kube.WaitForCacheSync("test", stop, c.queue.HasSynced)

			assert.EventuallyEqual(t, func() map[string]string {
				havePods := c.pods.List(metav1.NamespaceAll, klabels.Everything())

The Push Queue is mostly a normal queue, but it has some special logic to merge push requests for each given proxy. This results in each proxy having 0 or 1 outstanding push requests; if additional updates come in the existing push request is just expanded.

Another job polls this queue and triggers each client to start a push.

```mermaid
graph TD

  // +optional
  optional string apiVersion = 3;
}

// ExternalMetricSource indicates how to scale on a metric not associated with
// any Kubernetes object (for example length of queue in cloud
// messaging service, or QPS from loadbalancer running outside of cluster).
message ExternalMetricSource {
  // metric identifies the target metric by name and selector
  optional MetricIdentifier metric = 1;

  // API version of the referent
  // +optional
  optional string apiVersion = 3;
}

// ExternalMetricSource indicates how to scale on a metric not associated with
// any Kubernetes object (for example length of queue in cloud
// messaging service, or QPS from loadbalancer running outside of cluster).
// Exactly one "target" type should be set.
message ExternalMetricSource {
  // metricName is the name of the metric in question.

	so that we can remove stale entries when the ztunnel pod is deleted
	or when the ztunnel pod is restarted in the same pod (remove old entries when the same uid connects again, but with different boot id?)

	save a queue of what needs to be sent to the ztunnel pod and send it one by one when it connects.

	when a new ztunnel connects with different uid, only propagate deletes to older ztunnels.
*/

type connMgr struct {

	systemNamespace string

	queue      controllers.Queue
	pods       kclient.Client[*corev1.Pod]
	namespaces kclient.Client[*corev1.Namespace]
}

func setupHandlers(ctx context.Context, kubeClient kube.Client, dataplane MeshDataplane, systemNamespace string) *InformerHandlers {
	s := &InformerHandlers{ctx: ctx, dataplane: dataplane, systemNamespace: systemNamespace}
	s.queue = controllers.NewQueue("ambient",

                                  type: string
                                http1MaxPendingRequests:
                                  description: Maximum number of requests that will
                                    be queued while waiting for a ready connection
                                    pool connection.
                                  format: int32
                                  type: integer

}

// LimitResponse defines how to handle requests that can not be executed right now.
// +union
message LimitResponse {
  // `type` is "Queue" or "Reject".
  // "Queue" means that requests that can not be executed upon arrival
  // are held in a queue until they can be executed or a queuing limit
  // is reached.
  // "Reject" means that requests that can not be executed upon arrival
  // are rejected.

}

// LimitResponse defines how to handle requests that can not be executed right now.
// +union
message LimitResponse {
  // `type` is "Queue" or "Reject".
  // "Queue" means that requests that can not be executed upon arrival
  // are held in a queue until they can be executed or a queuing limit
  // is reached.
  // "Reject" means that requests that can not be executed upon arrival
  // are rejected.