Application name changes when adding additional port causing breaking change

[blafry]

Problem Description

When a service initially has only one port exposed, Wormhole creates an application without a port name suffix. However, when a second port is added to the same service, Wormhole changes the naming convention and adds port name suffixes to all applications, including the original one. This causes a breaking change for any integrations or applications that depend on the original service name.

Current Behavior

Initial state (service with 1 port):

apiVersion: v1
kind: Service
metadata:
  name: my-api
  namespace: production
  annotations:
    wormhole.glothriel.github.com/exposed: "yes"
spec:
  ports:
  - name: http
    port: 8080

Wormhole creates application named: production-my-api

After adding second port:

apiVersion: v1
kind: Service
metadata:
  name: my-api
  namespace: production
  annotations:
    wormhole.glothriel.github.com/exposed: "yes"
spec:
  ports:
  - name: http
    port: 8080
  - name: metrics
    port: 9090

Wormhole now creates applications named:

• production-my-api-http (previously production-my-api)
• production-my-api-metrics (new)

Impact

This breaking change causes:

1. Service disruption - Applications using production-my-api suddenly can't connect
2. DNS resolution failures - The Kubernetes service name changes
3. Configuration drift - Deployed applications have hardcoded service names that are now invalid
4. Zero-downtime deployment issues - No graceful transition between naming schemes

Expected Behavior

The application name should remain stable and predictable regardless of how many ports are added:

Option 1: Always use port suffixes

• Even for single-port services, use {name}-{port} format
• Consistent but requires initial configuration change

Option 2: Stable naming with explicit disambiguation

• First port keeps the base name without suffix
• Additional ports get suffixes: {name}-{port}
• Example: production-my-api (first port), production-my-api-metrics (second port)

Code Reference

The naming logic is implemented in pkg/k8s/svcdetector/service.go:108-111:

portName := wrapper.name()
if len(exposedPorts) > 1 {
    portName = fmt.Sprintf("%s-%s", wrapper.name(), portDefinition.Name)
}

Reproduction Steps

1. Deploy Wormhole with a service exposing 1 port
2. Configure client application to connect to the exposed service
3. Add a second port to the original service
4. Observe that the original service name changes and client connections fail

Proposed Solution

Implement Option 2 (stable naming) as it provides the best balance between backward compatibility and predictability:

1. Keep the first port without suffix (maintains backward compatibility)
2. Add suffixes only for additional ports
3. Consider the "first port" to be determined by:
   • Port order in the service spec (first in the list)
   • Or alphabetically by port name (for consistency)