influxdata / influxdata/kapacitor
Enabled task is not reloaded after updating it with HTTP PATCH request
- Dominant language
- Go
- Stars
- 2.4k
- Forks
- 479
- Avg merge
- 4d 16h
- Merged PRs (30d)
- 4
Description
## Description
When I update the TICKscript of an enabled task using a HTTP PATCH request, the task is not automatically reloaded by Kapacitor. Running `kapacitor show` does however show the updated script. To make Kapacitor use the updated script, I either have to use `kapacitor reload`, or disable and re-enable the task using two separate PATCH requests.
This behavior seems unintuitive to me, and I haven't read about it in the documentation. Is this the intended behavior of updating a task?
## Environment
* Xubuntu 16.04.2 LTS (64-bit)
* Docker version 17.05-0-ce, build 89658be
* Running Docker image `kapacitor:1.2`
* Kapacitor version 1.2.1 (git: master 4628bda2e3fbcc43df694707ec3f640f213cb0dc)
## Test case
* Create a new task with the following script: `stream|from().database('testdb').measurement('test')|log().prefix('prefix1')`
* Make sure the task is enabled.
* Insert a value into the measurement `test` of the database `testdb`.
* Kapacitor should log the measurement with prefix `prefix1`.
* Perform a PATCH request to change the script of the task to the following: `stream|from().database('testdb').measurement('test')|log().prefix('prefix2')`. Only the logging prefix is changed here.
* Run `kapacitor show` with the ID of the task. It should show the newly updated script.
* Insert a value, just like before.
* Kapacitor should still log the measuremen with prefix `prefix1`.
* Reload the task, either by using `kapacitor reload` or by using two PATCH requests that disable and re-enable the task.
* Now Kapacitor should log the measurement with the new prefix `prefix2`.
Contributor guide
Research direction
Start by reproducing the HTTP PATCH flow for an enabled task, then compare the behavior of `kapacitor show`, `kapacitor reload`, and disable/re-enable PATCH requests. Trace the API entry point that updates the task and determine whether the intended behavior is immediate reloading; done means the behavior is resolved or clearly documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100