DBRP mapping being ignored

I have set up a DBRP mapping according to the Influx documentiation, but it appears that it is being ignored when I try to make a API query through curl as no data is being returned. Issue occurred with InfluxDB 2.0.4 running under docker on Debian 10.

Running the following on the Influx CLI:

influx v1 dbrp list -o spiro -t <token>

yields

ID			Database	Bucket ID		Retention Policy	Default	Organization ID
0743c2ae30a58000	empc_demo	b19272847848e4de	autogen	true    bbf4fcb660e98f19

Querying the dbrp endpoint with the appropriate authorization header returns the expected response:

{
"content": {
"id": "0743c2ae30a58000",
"database": "empc_demo",
"retention_policy": "autogen",
"default": true,
"orgID": "bbf4fcb660e98f19",
"bucketID": "b19272847848e4de"
  }
}

When I run a flux query through the Influx2 API with curl, such as:

curl --request POST http://127.0.0.1:8086/api/v2/query?org=spiro --header "Authorization: Token 
<token>" --header 'Accept: application/csv' --header 'Content-type: application/vnd.flux' --data 
"'import "influxdata/influxdb/schema'
schema.measurements(bucket: "empc_demo")" -v

I get a long list of measurements including:

,_result,0,task_scheduler_total_execute_failure
,_result,0,task_scheduler_total_execution_calls
,_result,0,task_scheduler_total_release_calls
,_result,0,task_scheduler_total_schedule_calls
,_result,0,task_scheduler_total_schedule_fails
,_result,0,variables_float

If I try to get the same information using the Influx QL endpoint as:

curl --request GET http://127.0.0.1:8086/query?org=spiro?database=empc_demo --header 
"Authorization: Token <token>" --header "Accept: application/json" -v --data-urlencode "q=SHOW 
MEASUREMENTS ON empc_demo"

the the response is just an empty json object i.e. {}.

Influx log shows:

ts=2021-03-23T15:42:19.078320Z lvl=info msg="executing new query" log_id=0T3eeSIG000 query=

I have tried a number of other queries and the behavior is always the same. Am I missing some step to “activate” the dbrp mapping?

@adm78 I’ve seen some strange behavior when sending GET requests to the V1 compatibility endpoint, and haven’t had the chance to dig into it yet (see this issue for progress once I get around to it). In the meantime, could you try POST-ing your query instead?