influxdata / influxdata/influxdb
Flux tasks.lastSuccess function does not return the last successful runtime of a task
- Dominant language
- Rust
- Stars
- 31.7k
- Forks
- 3.7k
- Avg merge
- 13h 37m
- Merged PRs (30d)
- 8
Description
__Steps to reproduce:__
List the minimal actions needed to reproduce the behaviour.
1. In InfluxDB OSS v2 or InfluxDB Cloud (TSM), create a new bucket named `last_success_test`.
2. In InfluxDB v2, create a new task that uses `tasks.lastSuccess()` to return the time of the last successful task run and write it to the `last_success_test` bucket. If `tasks.lastSuccess()` doesn't get the last successful task run time from InfluxDB, it returns the `orTime` value of `now()` (the same as the `_time`). If `tasks.lastSuccess()` works properly, the `_value` should be 1 minute ahead of the `_time` value.
```javascript
import "array"
import "influxdata/influxdb/tasks"
option task = {
name: "lastSuccess test",
every: 1m,
}
array.from(rows: [
{_measurement: "test", _time: now(), _field: "last_success", _value: "${tasks.lastSuccess(orTime: now())}"}
])
|> to(bucket: "last_success_test")
```
3. Let the task run a few times.
4. Run the following query to see if the data the task is writing to the bucket shows that the `tasks.lastSuccess()` function is or is not working:
```javascript
from(bucket: "last_success_test")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "test")
|> filter(fn: (r) => r["_field"] == "last_success")
|> keep(columns: ["_time", "_field", "_value"])
|> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
|> map(fn: (r) => ({r with last_success_correct: if r._time == time(v: r.last_success) then false else true}))
```
__Expected behaviour:__
If the function were returning properly, the data the task writes would include `_time` value that's different than the `last_success` field value. The `last_success` value should actually be 1 minute ahead of the `_time`. Something like this:
| _time | last_success | last_success_correct |
| :----------------------- | :----------------------------- | -------------------: |
| 2024-09-24T14:16:00.000Z | 2024-09-24T14:15:00.000000000Z | true |
| 2024-09-24T14:17:00.000Z | 2024-09-24T14:16:00.000000000Z | true |
| 2024-09-24T14:18:00.000Z | 2024-09-24T14:17:00.000000000Z | true |
| 2024-09-24T14:19:00.000Z | 2024-09-24T14:18:00.000000000Z | true |
| 2024-09-24T14:20:00.000Z | 2024-09-24T14:19:00.000000000Z | true |
__Actual behaviour:__
In the query results, the `_time` and the `last_success` are the same, meaning `tasks.lastSuccess()` is defaulting to the `orTime`, which in this case is `now()` (the task run time), even though the last successful task run time is one minute before:
| _time | last_success | last_success_correct |
| :----------------------- | :----------------------------- | -------------------: |
| 2024-09-24T14:16:00.000Z | 2024-09-24T14:16:00.000000000Z | false |
| 2024-09-24T14:17:00.000Z | 2024-09-24T14:17:00.000000000Z | false |
| 2024-09-24T14:18:00.000Z | 2024-09-24T14:18:00.000000000Z | false |
| 2024-09-24T14:19:00.000Z | 2024-09-24T14:19:00.000000000Z | false |
| 2024-09-24T14:20:00.000Z | 2024-09-24T14:20:00.000000000Z | false |
This has been reported in the Flux repo (https://github.com/influxdata/flux/issues/3430, https://github.com/influxdata/flux/issues/5498), but I have a feeling this is an issue on the InfluxDB side, specifically with the lastSuccess API.
Contributor guide
Research direction
Start by comparing the reported tasks.lastSuccess behavior with the referenced Flux issues 3430 and 5498, then investigate the InfluxDB lastSuccess API mentioned in the report. Done means repeated task runs return the previous successful runtime rather than the orTime value of the current run.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend-api-design, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100