bug(prometheus): remote_read does not honor custom timestamp and value column names

What type of bug is this?

Incorrect result, Unexpected error

What subsystems are affected?

Write Protocols, Frontend, Query Engine

Minimal reproduce step

Prometheus remote write can accommodate an existing metric table whose timestamp and single Float64 value columns use names different from the process-wide defaults. However, remote read still looks up the columns through greptime_timestamp() and greptime_value() instead of resolving them from the table schema.

1. Start GreptimeDB without changing default_column_prefix.
2. Pre-create a physical metric table and a logical metric table with custom timestamp/value column names:

CREATE TABLE custom_phy (
    custom_ts TIMESTAMP TIME INDEX,
    custom_value DOUBLE
) ENGINE = metric
WITH ("physical_metric_table" = "");

CREATE TABLE custom_metric (
    custom_ts TIMESTAMP TIME INDEX,
    custom_value DOUBLE,
    job STRING PRIMARY KEY
) ENGINE = metric
WITH ("on_physical_table" = "custom_phy");

3. Send Prometheus remote-write samples for custom_metric, selecting custom_phy as the physical table. The existing-schema write alignment maps the incoming Prometheus timestamp/value columns to custom_ts and custom_value.
4. Send a Prometheus remote-read request for __name__="custom_metric".

Relevant code paths:

• Existing-schema write alignment:
  • src/operator/src/insert.rs
  • src/servers/src/prom_row_builder.rs
• Remote-read fixed-name lookups:
  • query_to_plan() in src/servers/src/prom_store.rs builds the time filter with greptime_timestamp().
  • collect_timeseries_ids() excludes only greptime_timestamp() and greptime_value().
  • recordbatch_to_timeseries() retrieves columns only by greptime_timestamp() and greptime_value().

Note that globally configured names through default_column_prefix already work because all of these call the same global getters. The problem is limited to arbitrary names obtained from an existing table schema.

A possible fix is to resolve the time-index column and the single Prometheus value field from the table/DataFrame schema, pass those names through query planning and result conversion, and add a remote-read regression test with custom_ts/custom_value.

What did you expect to see?

Remote read should use the metric table schema to locate custom_ts and custom_value, and return the same samples that were accepted by remote write.

What did you see instead?

Remote read references the process-wide default column names. Query planning can fail because greptime_timestamp is absent. If conversion is reached with differently named result columns, it reports that the greptime_timestamp or greptime_value column is missing.

What operating system did you use?

N/A — identified through code inspection; the issue is platform-independent.

What version of GreptimeDB did you use?

Current main checkout at 598a412fbb55.

Relevant log output and stack trace

No runtime log captured. Static inspection shows fixed-name lookups in src/servers/src/prom_store.rs.