Refactoring: Endpoint processQuery should consider a parameter to ignore queue tasks

Description

PRDE - Story default text according to the team DoR (Definition of Ready)

01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):
02 - STORY BRIEFING (AS A < PERSONA >, I [WANT TO] < NEED >, [SO THAT] < GOAL >):
03 - PROBLEM (WHAT'S THE CURRENT PROBLEM SCENARIO OR PAIN TO BE RESOLVED?):

Some projects are defining a frequency to process pipeline very shorter. We need to allow to call the endpoint “processQuery” (/api/v2/bigQuery/processQuery) in a way that we can ignore creating tasks in case there is a running task or a queued task.

04 - GOAL (DESCRIBE THE PROPOSED SOLUTION):

Create a new parameter on endpoint “processQuery” (/api/v2/bigQuery/processQuery) that could be called createIfRunningOrQueuedTasks and have a default value as FALSE .

This endpoint should also have a new, not mandatory, parameter to define the pipeline name.

Every task created to process data (SQL Processing tasks) should store the pipeline name, in the same way the unified does today.

This is the expected behavior for the new parameter createIfRunningOrQueuedTasks:

True: It will create the SQL Processing tasks as today,it means it will not validate if the tenant already has tasks for this data model or pipeline (today there are no validation related to existing tasks).

False: The endpoint will validate if there is another task for the same pipeline name RUNNING or QUEUED. If there is another task running or queued, we should return a specific HTTP response (I think 200 is OK) and we can return the existing task’s document.

Point of attention:

  • we are not changing the behavior related to tasks, we are changing the behavior when creating the SQL Processing tasks (/api/v2/bigQuery/processQuery).
  • We are validating the pipeline name, something new for the endpoint/api/v2/bigQuery/processQuery“. The validation shouldn't be related to data model name.
  • The endpoint should ignore the parameter `createIfRunningOrQueuedTasks` if the pipeline name is null or empty (pipelineName.trim().length()).

05 - WHO CAN USE THIS FEATURE (USER ROLES):
06 - ACTIVITY DIAGRAM (ACTIVITY DIAGRAM LINK AND IMAGE):
07 - STEPS (ACTIONS TO BE PERFORMED LINKING TO SCREENSHOTS):
08 - ALTERNATIVE STEPS:
09 - ASSETS (FIGMA LINKS, RELEVANT DOCUMENTATION LINKS, JSON EXAMPLES, ETC):
10 - ACCEPTANCE CRITERIA:

  • Tasks with the pipeline name, for processData sending this new optional parameter.
    • validate it is optional.
  • For the new flag that validates if there is another existing task for the same pipeline name:

This is the expected behavior for the new parameter `createIfRunningOrQueuedTasks`:

True: It will create the SQL Processing tasks as today,it means it will not validate if the tenant already has tasks for this data model or pipeline (today there are no validation related to existing tasks).

False: The endpoint will validate if there is another task for the same pipeline name RUNNING or QUEUED. If there is another task running or queued, we should return a specific HTTP response (I think 200 is OK) and we can return the existing task’s document.

  • The endpoint should ignore the parameter `createIfRunningOrQueuedTasks` if the pipeline name is null or empty (pipelineName.trim().length()).