Error unknown field type despite successful task run

[ghost]

Steps to reproduce:
List the minimal actions needed to reproduce the behavior.

1. Ensure Telegraf is running and collecting system metrics into an input bucket. Create a second bucket for output.
2. Generate a task that looks like this:

option task = { 
  name: "cpu_mean",
  every: 15s,
}

data = from(bucket: "InputBucket")
    |> range(start: -task.every)
    |> filter(fn: (r) =>
        (r._measurement == "cpu" and r._field == "usage_idle"))

data
    |> aggregateWindow(every: 5m, fn: mean)
    |> to(bucket: "OutputBucket", org: "YourOrg")

3. Run the task and confirm that OutputBucket is indeed collecting your downsampled data.
4. Check 2.0 logs and see an error like this repeating, despite the task having run successfully:

2019-07-01T18:28:45.102625Z    info    Error exhausting result iterator    {"log_id": "0GNhMwWl000", "service": "task-executor", "task_id": "0417b1ad4d7a8000", "run_id": "0417b250ddfa8000", "op_name": "execute", "error": "unknown field type for usage_idle: \u0004\u0001J@\ufffd^\\ \u0000\u0004\u0017\ufffdȊ\ufffd\\ \u0000,\u0000=cpu,cpu=cpu-total,host=Your-MacBook-Pro-2.local,\ufffd=usage_idle usage_idle= 1562005725000000000", "name": "to7"}

Expected behavior:
I expect to see clean logs.

Actual behavior:
Logs have a repeating error despite the task running successfully.

Environment info:

• System info: Darwin 17.7.0 x86_64
• InfluxDB version: 2.0 alpha 13
• Other relevant environment details: Container runtime, disk info, etc

Config:
Copy any non-default config values here or attach the full config as a gist or file.

Logs:
Include snippet of errors in log.

Performance:
Generate profiles with the following commands for bugs related to performance, locking, out of memory (OOM), etc.

# Commands should be run when the bug is actively.
# Note: This command will run for at least 30 seconds.
curl -o profiles.tar.gz "http://localhost:8086/debug/pprof/all?cpu=true"
curl -o vars.txt "http://localhost:8086/debug/vars"
iostat -xd 1 30 > iostat.txt
# Attach the `profiles.tar.gz`, `vars.txt`, and `iostat.txt` output files.

[ghost]

Relevant portions of the code:

influxdb/tsdb/tsm1/value.go

Lines 104 to 107 in 90a529e

	default:
	return nil, fmt.Errorf("unknown field type for %s: %s",
	string(iter.FieldKey()), p.String())
	}

influxdb/task/backend/executor/executor.go

Lines 183 to 185 in 90a529e

	if err := exhaustResultIterators(res); err != nil {
	p.logger.Info("Error exhausting result iterator", zap.Error(err), zap.String("name", res.Name()))
	}

[GeorgeMac]

I am also experiencing this issue. Thought I would contribute the output I am seeing:

For Task:

option task = {name: "Daily Memory Usage", every: 24h, offset: 2m}

data = from(bucket: "primary")
	|> range(start: -task.every)
	|> filter(fn: (r) =>
		(r._measurement == "mem"))

data
	|> aggregateWindow(every: 1h, fn: mean)
	|> to(bucket: "primary_downsampled", org: "InfluxData")

Where the primary bucket contains the system metrics from the example telegraf config. I am attemping to downsample all the memory fields for the past 24 hours into 1 hour average windows.

I get the following log output:

2019-07-03 14:20:47 | Started task from script: "option task = { \n  name: \"Daily Memory Usage\",\n  every: 24h,\n  offset: 2m\n}\n\n// Data source\ndata = from(bucket: \"primary\")\n  \|> range(start: -task.every)\n  \|> filter(fn: (r) =>\n    r._measurement == \"mem\"\n  )\n\ndata\n  // Data transformation\n  \|> aggregateWindow(\n    every: 1h,\n    fn: mean\n  )\n  // Data destination\n  \|> to(bucket: \"primary_downsampled\", org: \"InfluxData\")"
-- | --
2019-07-03 14:20:48 | {"total_duration":99136784,"compile_duration":2099,"queue_duration":23141,"plan_duration":0,"requeue_duration":0,"execute_duration":99098371,"concurrency":0,"max_allocated":4711184,"runtime_errors":["unknown field type for active: \u0004\u0019\u001eq0\ufffd0\u0000\u0004\u0019\ufffd\u0005\ufffd\u0007\ufffd\u0000,\u0000=mem,host=ip-192-168-1-125.ec2.internal,\ufffd=active active= 1562076000000000000"],"metadata":{"influxdb/scanned-bytes":[2522944],"influxdb/scanned-values":[315368]}}
2019-07-03 14:20:48 | Completed successfully

Looks like the same issue you are seeing. Thought the extra example might aid in debugging.