Kong 3.7: Upstream Hash Fallback Issue - All Requests Route to First Target When Hash on header is Missing

[zhou-cl]

Hi Kong Community,
I'm encountering an issue with Kong 3.7's upstream hash configuration. I'm hoping someone can help me understand why all requests are being routed to the first target when the Hash on header header is missing.
Environment:
Kong Version: 3.7
Upstream Configuration:
{
"hash_fallback": "none",
"name": "admin-scm_Upstream_testaws",
"hash_on_header": "pp-depot-hashid",
"hash_on_query_arg": null,
"id": "1633806f-163a-46dd-ad34-0611cdd1a0ee",
"hash_on_uri_capture": null,
"hash_on_cookie": null,
"hash_on_cookie_path": "/",
"hash_fallback_query_arg": null,
"hash_fallback_uri_capture": null,
"host_header": null,
"client_certificate": null,
"use_srv_name": false,
"tags": ["k8s-1739002503300704098"],
"algorithm": "consistent-hashing",
"slots": 10000,
"hash_on": "header",
"hash_fallback_header": "pp-userid",
"created_at": 1589536188,
"updated_at": 1739002503
}
I have three targets configured for this upstream.
When the pp-depot-hashid header is missing, all requests are being routed to the first target.
This behavior does not occur in Kong 1.5.1, where requests are distributed among all targets when pp-depot-hashid is missing.
Expected Behavior:
When pp-depot-hashid is missing, requests should be distributed among all targets using the default load balancing strategy (e.g., round-robin).
Actual Behavior:
All requests are routed to the first target when pp-depot-hashid is missing.
Steps to Reproduce:
Configure an upstream with hash_on_header: pp-depot-hashid and hash_fallback: none.
Add three targets to the upstream.
Send requests without the pp-depot-hashid header.
Observe that all requests are routed to the first target.
Questions:
Is this a known issue in Kong 3.7?
Are there any configuration changes or workarounds to ensure requests are distributed among all targets when pp-depot-hashid is missing?
Why does this behavior differ from Kong 1.5.1?
Thank you in advance for any insights or assistance!

[nowNick]

Resolved in: #14251