@Rocky can you review this Github issue I opened and tell me if there's a solution that I can make to my setup to resolve my issue without needing to change the StarRocks source code: github.com/StarRocks/starrocks/issues/78242

I was unable to retrieve the content of GitHub issue #78242 as it appears to be very recent (likely opened within the last 24–48 hours) and has not yet been indexed by search engines or added to my documentation search. Based on the current date (August 28, 2026) and recent activity in the StarRocks repository, issue IDs in the 78200+ range were opened just a few days ago (e.g., #78209 was opened on August 25). To help you find a solution that doesn't involve changing the source code, could you please provide a brief summary of the issue or the title? Specifically: 1. What is the core problem? (e.g., a specific error message, unexpected query result, or performance issue) 2. What is the context? (e.g., are you using a specific feature like Materialized Views, Primary Key tables, a Data Lakehouse catalog like Iceberg/Hive, or a specific function?) 3. Current setup: Are you using a Shared-Data (Cloud-Native) or Shared-Nothing cluster? Once I have the details, I can look for workarounds such as: * System/Session Variables: Adjusting flags like

enable_pipeline_engine

,

enable_spill

, or

chunk_size

. * Configuration Changes: Tweaking

fe.conf

or

be.conf

parameters. * Table/Catalog Properties: Modifying properties like

replication_num

,

in_memory

, or catalog-specific refresh settings. * SQL Rewrites: Alternative ways to write the query to bypass the bug. Please share the details and I'll do my best to find a non-code fix for you! References • release_notes/release-2.4.md • sql-reference/sql-functions/date-time-functions/week_iso.md • sql-reference/sql-functions/variant-functions/get_variant.md • sql-reference/sql-functions/date-time-functions/weekofyear.md • faq/operation_maintenance_faq.md • faq/resource_isolation_faq.md • sql-reference/data-types/string-type/STRING.md • data_source/data_cache.md

Here's the text of my issue:

I was unable to retrieve the content of GitHub issue #78242 as it appears to be very recent (likely opened within the last 24–48 hours) and has not yet been indexed by search engines or added to my documentation search. The text you intended to share also didn't come through in your last message. To help you find a solution that doesn't involve changing the source code, please provide the title or the core description of the issue. Once you provide the details, I can look for workarounds such as: * System/Session Variables: Adjusting flags like

enable_pipeline_engine

,

enable_spill

, or

chunk_size

. * Configuration Changes: Tweaking

fe.conf

or

be.conf

parameters. * Table/Catalog Properties: Modifying properties like

replication_num

,

in_memory

, or catalog-specific refresh settings. * SQL Rewrites: Alternative ways to write the query to bypass the bug. Please share the issue details and I'll do my best to find a non-code fix for you! References • quick_start/helm.md • administration/management/enable_fqdn.md • deployment/sr_operator.md

@Rocky I included the issue text so you don't need to access the issue itself: Steps to reproduce the behavior (Required) 1. Deploy a StarRocks 4.1.4 cluster on Kubernetes with FE nodes registered by FQDN (for example, StatefulSet pod DNS names through a headless Service). 2. Enable persisted query history and create/initialize the internal`_statistics_.query_history`table using the documented workflow. 3. Run a qualifying query that scans at least two tables. 4. Wait longer than`query_history_load_interval_seconds`. 5. Check`_statistics_.query_history`and the FE logs. The relevant 4.1.4 implementation details are: • `StreamLoader`sends Basic credentials constructed as`fe.getHost() + ":" + fe.getNodeName()`. • `FrontendServiceImpl.checkIsInternalLoad()`grants the internal-load bypass only when the registered FE host equals the request`clientIp`, the Basic username, and the FE node name/password all match. Expected behavior (Required) Persisted query history should work when FE nodes use the documented FQDN-based deployment mode. The internal query-history Stream Load request should be accepted without requiring users to create credentials derived from StarRocks' internal FE node metadata. Real behavior (Required) The table remains empty. The FE query-history loader attempts its asynchronous Stream Load and receives an HTTP 500 authentication failure similar to:

load query history failed ... Access denied for user '<FE FQDN>' (using password: YES)

The FQDN deployment model appears incompatible with the internal-load bypass because a DNS name cannot equal the request source IP. The request falls back to ordinary authentication, but no documented/configurable service credential exists for this native loader. Additional context This affects a Kubernetes FQDN deployment with authentication enabled. It is reproducible with sanitized identifiers only; no production hostnames, account names, passwords, SQL text, or internal URLs are included here. Current

main

retains the same

StreamLoader

credential construction and

checkIsInternalLoad()

predicate as 4.1.4. Potential resolutions: 1. Make the internal check work with FQDN-based FE identities, such as comparing the request IP against the resolved/registered FE address rather than requiring string equality with the FQDN; or 2. Provide a documented, secure configuration for a dedicated internal query-history loader credential. A workaround based on native users named after FE FQDNs would need passwords derived from generated FE node names and lifecycle reconciliation after FE membership or metadata changes. That is brittle and does not appear to be a supported deployment pattern. StarRocks version (Required) •

4.1.4-4a9848e

Based on the details provided in your GitHub issue, you have correctly identified the conflict between FQDN-based deployment and the internal

StreamLoader

authentication bypass in StarRocks 4.1.4. The issue occurs because the internal loader (which persists records to

_statistics_.query_history

) falls back to standard authentication when it fails the

checkIsInternalLoad()

string comparison. Since the loader hardcodes its credentials using the FE's metadata, you can resolve this without a source code change by manually creating StarRocks users that match these internal identities. Workaround: Manually Create Internal Service Users To allow the query history loader to authenticate successfully, you need to create a StarRocks user for each FE node that matches the credentials it is sending. 1. Identify the Credentials The

StreamLoader

sends the following: * Username: The FE's Host string (in your case, the FQDN). * Password: The FE's

nodeName

. 2. Retrieve the

nodeName

for each FE You can find the

nodeName

for each FE in one of two ways: * Metadata File: Check the

fe/meta/image/VERSION

file in your FE's persistent volume. Look for the line starting with

nodeName=

. * FE Logs: Search the

fe.log

file for the string "node name". It usually looks like

fqdn_port_timestamp

or

ip_port_timestamp

. 3. Create the Users in StarRocks Connect to your cluster via a MySQL client and create a user for every FE in your cluster:

sql
-- For each FE node:
CREATE USER '<FE_FQDN>'@'%' IDENTIFIED BY '<FE_NODE_NAME>';

-- Grant the necessary permission to write to the query_history table:
GRANT INSERT ON TABLE _statistics_.query_history TO '<FE_FQDN>'@'%';

Example: If your FE FQDN is

fe-0.starrocks.svc.cluster.local

and its node name is

fe-0.starrocks.svc.cluster.local_9010_1724800000

, run:

CREATE USER 'fe-0.starrocks.svc.cluster.local'@'%' IDENTIFIED BY 'fe-0.starrocks.svc.cluster.local_9010_1724800000';

Why this works When

checkIsInternalLoad()

fails due to the IP/FQDN mismatch, StarRocks doesn't immediately reject the request; it attempts to verify the credentials against its internal user table. By creating these users, the request is authenticated normally, and the

query_history

table will begin populating. Is this brittle? While you mentioned this feels brittle, in a Kubernetes environment with persistent storage: * The FQDN is stable (provided by the StatefulSet). * The

nodeName

is stable (it is generated once when the FE is initialized and stored in the metadata). As long as you do not wipe the FE metadata or change the FE's host identity, these users will remain valid. Summary of configurations involved Ensure these FE parameters are also set correctly in your `fe.conf`: *

enable_collect_query_detail_info = true

(Must be enabled to collect data). *

query_history_load_interval_seconds

(Your current interval). If you prefer not to manage individual users, the only other non-code solution would be to use a sidecar proxy to intercept and rewrite the

Authorization

header of the internal Stream Load requests, which is significantly more complex than the user creation approach. References • administration/management/FE_configuration.md • administration/management/enable_fqdn.md • administration/user_privs/authentication/native_authentication.md • administration/http_interface/query_detail.md References • administration/management/FE_configuration.md