influxdata / influxdata/influxdb

Flux tasks.lastSuccess function does not return the last successful runtime of a task

Open
#25,384 0 comments 1 reaction 0 assignees View on GitHub
kind/bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.