Sticky session ID and balancer outcome not logged — makes debugging affinity routing impossible

[sg-shag]

Olla's sticky session balancer computes affinity keys and tracks outcomes (hit/miss/repin/disabled), but none of this information appears in request logs.

The X-Olla-Session-ID header is set by clients, used by ComputeStickyKey() to derive affinity keys, and echoed back in responses — but the actual session ID and sticky outcome are never logged.

Currently, handler_proxy.go logs at INFO and DEBUG levels, but neither includes:

• session_id (the X-Olla-Session-ID value)
• sticky_outcome (hit / miss / repin / disabled)
• sticky_source (session_header / prefix_hash / auth_header / ip)

This makes it impossible to answer questions like:

• Was this request routed by sticky session or full round-robin?
• Is the sticky session cache filling up with dead keys?
• Why did a request go to a different backend than expected?

Suggested fix:
Add session_id and sticky_outcome fields to the INFO-level log in logRequestStart() and logRequestResult(), and optionally include sticky_source in DEBUG logs. These fields should be read from the request context keys:

• constants.ContextStickyKeyKey → session ID
• constants.ContextStickyKeySourceKey → key source
• constants.ContextStickyOutcomeKey → outcome (hit/miss/repin/disabled)

Example INFO log would gain:

"session_id": "a1b2c3d4e5f6...", "sticky_outcome": "hit", "sticky_source": "session_header"

[thushan]

Good catch, thanks, also great examples and reasoning.

Let me get back to you around this.

[thushan]

@sg-shag are you able to see if the PR #182 is helpful?

[sg-shag]

@thushan are you able to see if the PR #182 is helpful?

Yes, I tested PR #182 on our live Thunder Forge setup with the binary built from commit b76ea15, and it is helpful.

What I confirmed:

• Sticky routing is working.
• Edge logs show stable sticky_id across requests.
• Olla handles the requests correctly.

What is still missing:

• For our traffic path, requests hit /olla/omlx/v1/chat/completions, which goes through providerProxyHandler.
• session_id and sticky_outcome are not being copied into the final Request completed INFO log fields on that provider handler path.
• Those fields are captured on proxy/translation handler paths, so the fix appears partial rather than wrong.

So overall: PR #182 is good and moves things forward, but it needs one additional providerProxyHandler logging hookup for full INFO-level visibility on provider routes.

[thushan]

ah yes, good point, i forgot to capture that, fixed (I hope).

[sg-shag]

ah yes, good point, i forgot to capture that, fixed (I hope).

It works, thank you!