[Bug][TimeAfter] Bug title The timeAfter parameter in the DevLake sync API isn't functioning as expected.

[SushmitaMahapatra23]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

The timeAfter parameter in the DevLake sync API isn't functioning as expected; it's using the time range configured in the config-ui instead.

ex:

curl -X 'POST'   'http://localhost:4001/api/rest/blueprints/4/trigger'   -H 'accept: application/json'   -H 'Content-Type: application/json'   -H 'Authorization: Bearer <token>'   -d '{
  "fullSync": true,
  "skipCollectors": false,
  "skipOnFail": false,
  "timeAfter": "2024-08-11T05:00:00Z"
}'

What do you expect to happen

The timeAfter value provided in the API parameter should take precedence over the default timeRange in DevLake.

How to reproduce

curl -X 'POST' \
  'http://localhost:4001/api/rest/blueprints/4/trigger' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <token>' \
  -d '{
    "fullSync": true,
    "skipCollectors": false,
    "skipOnFail": false,
    "timeAfter": "2024-08-11T05:00:00Z"
  }'

Monitor the sync process and observe whether it respects the timeAfter parameter you provided.
Verify if the sync is using the time range from the config-ui instead.

Expected Behaviour

The sync process should respect the timeAfter parameter provided in the API call and use "2024-08-11T05:00:00Z" as the starting point.

Actual Behavior

The sync process ignores the timeAfter parameter and uses the time range configured in the config-ui.

Anything else

No response

Version

v0.17.0-beta2

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[dosubot]

Hello @SushmitaMahapatra23! I'm here to assist you with any bugs, questions, or contributions you may have for the DevLake repository. I'm a bot designed to help you while you wait for a human maintainer.

The timeAfter parameter in the DevLake sync API is not functioning as expected and instead using the time range configured in the config-ui because the synchronization policy set in the Config UI takes precedence over API parameters. The Config UI allows users to specify the sync frequency, time range, and other options, which are then used during the data collection process.

According to the DevLake documentation, the synchronization policy includes a "Time Filter" that allows users to select the desired time range for syncing data. This configuration is applied when the data collection process is initiated, overriding any timeAfter parameter passed directly to the API ^[1][2][3][4].

Additionally, the UI components such as DatePicker and quick selection Tag elements update the timeAfter value based on user interactions, which further ensures that the time range configured in the UI is used during synchronization ^[5].

For debugging, you can refer to the test cases in TestSubtaskStateManager, which verify the behavior of the timeAfter parameter under various conditions. These test cases can help trace the handling of the timeAfter parameter during a sync request ^[6][7].

To continue talking to Dosu, mention @dosu.

[klesh]

@SushmitaMahapatra23 After some investigation, we found out the skipOnFail and timeAfter were not used by trigger API at all, we believe it was a mistake to put them in the request body in the first place.
I think you can use the PATCH bluepint API first if you wish to change these options.