⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Startup now blocks for ~47.5 seconds when LDAP is unavailable.

The startup reconnect logic introduces a significant delay. With a 10-second initial interval, 1.5× multiplier, and 3 max tries, the total wait is approximately 47.5 seconds before failing. This blocks application startup whenever LDAP is unreachable.

Impact: Based on the upstream caller (BootstrapApp.setupServices), the application is designed to tolerate LDAP initialization failure and continue without it. The new blocking retry degrades startup time from immediate to ~47.5 seconds in environments where LDAP is down or misconfigured. This affects deployment, development, and testing workflows.

Suggestions:

• Consider removing the startup reconnect entirely and rely only on the heartbeat reconnect (which already handles connection recovery after startup).
• If startup reconnect is essential, use a much shorter total timeout (e.g., 1-2 tries with 2-3 second intervals) to fail faster.
• Update or remove the "45 seconds" comment to reflect the actual ~47.5-second delay.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/service/ldap_service.go` around lines 66 - 70, The startup blocking
retry in ldap_service.go (the call to ldap.reconnect(...) inside the error
branch after connection attempt) causes ~47.5s delay; either remove this startup
reconnect entirely so setup continues on LDAP failure (relying on existing
heartbeat reconnect logic), or drastically shorten it (e.g., call ldap.reconnect
with a single short interval / 1–2 second attempts or implement max 1-2 retries)
and update the comment to reflect the actual delay; locate the error handling
around ldap.reconnect and adjust the call and/or comment accordingly so
BootstrapApp.setupServices will not block for ~47.5s when LDAP is unavailable.

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Critical logic error: successful reconnect still returns nil service.

If the initial connection fails but reconnect succeeds, this code still returns a nil service pointer and an error. Line 69 executes unconditionally when the initial connect fails, regardless of whether the reconnect succeeded.

Impact: When reconnect succeeds, the LDAP connection is established (ldap.conn is valid and ldap pointer exists), but NewLdapService returns nil to the caller. Downstream code (like AuthService.GetLDAPUser) will report "ldap service not configured" even though the connection is active.

 if err != nil {
 	err = ldap.reconnect(10 * time.Second)
-	return nil, fmt.Errorf("failed to connect to ldap server: %w", err)
+	if err != nil {
+		return nil, fmt.Errorf("failed to connect to ldap server: %w", err)
+	}
 }

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/service/ldap_service.go` around lines 67 - 69, The logic in
NewLdapService incorrectly returns nil even when ldap.reconnect succeeds: adjust
the error handling in the initial connect branch (where err != nil) to call
ldap.reconnect(10 * time.Second) and check its return error; if reconnect
returns nil then return the ldap pointer and nil error, otherwise return nil and
the wrapped reconnect error (fmt.Errorf("failed to connect to ldap server: %w",
err)). Ensure you reference the ldap variable created in NewLdapService and only
return nil when reconnect actually fails.