Provide capability to retrieve task by specific call ID

[denismakogon]

Since async route execution returns call_id from user perspective it would be useful to get execution task instead of querying all tasks by sending HTTP GET to /tasks

Proposal

Implement new HTTP route /tasks/{call_id}

Returns: Single task entry data

HTTP errors:

• HTTP 404 Task not found

Aside change:

Consider to bring consistency in naming: async execution return call_id, but in order to get info users are querying for /tasks. So, it is necessary to change call_id to task_id for naming consistency.

[ucirello]

I am sorry, the usefulness it not evident for me. Could you please put forward a concrete case in which this is a superior replacement for the current flow?

[denismakogon]

@ccirello current there's no way to get info on specific task, in order to accomplish task retrieving it is required to iterate over all existing tasks, for some cases it would take some time to get proper one. Isn't it a valid reason to have new route?

[ucirello]

@denismakogon what's the intent here? I am afraid I do not follow your reasoning. The worker alone should be the entity talking to /tasks endpoint. And it must be able to read the task it's been assigned to. Why do you need to have this entrypoint? Which component will be talking to it, and do you expect this component to achieve with the payload that, in theory, only interests to the worker?

[denismakogon]

@ccirello The idea was to provide capability to get exit status of a function to users, since task payload includes exit status, we can get it and send back to users as part of response to status check for async function execution by its call_id and then i've faced with problem - i can get all tasks (assume that IronFuntions is shared between multiple users in OpenStack, in my particular case - 6 users trying to run their functions). So, that's why i created this issue - for simplifying process of getting task status. Am i missing something or using /tasks in wrong way?

[denismakogon]

@treeder @seiflotfy @pedronasser @derekschultz guys, may i ask you for an input on this topic? We still don't have a mechanism for IronFn users to track their async executions and may be increase time to keep task data for a specific execution a bit longer?

[denismakogon]

Related to https://github.com/iron-io/functions/issues/528

[treeder]

I think this makes sense, but currently we don't keep track of any task status, other than outputting it to the logs. We probably do need to have this for async tasks, otherwise there's no way to check if a task was successful or not (other than parsing logs).

But how does this relate to #528?

[denismakogon]

@treeder assume that you want to delete an app with routes and async functions that is in progress right now. So in order to delete that route we need to clarify that executions already finished. So we can solve this in two ways - give to users an ability to track their async executions using /tasks/{call_id} or enable app deletion (with routes, for now API return HTTP 403 when attempting to delete an app with routes) if there's no active executions on each route.

[seiflotfy]

I gave this a second thought, I already proposed my idea to @treeder but I think its worth bringing it out there again. I was thinking of having a "middle-ware" that just tracks the logs output... It would work as follows in the middle-ware:

• Upon async request store request ID in DB and state "init"
• Monitor logs for state change (the runner and functions spit out when something is about to run or finished running with that request-id), and update DB accordingly Pretty simple and not intrusive. WDYT? @ccirello

[gouthamve]

@seiflotfy Instead of complicating it by adding log monitoring, can we not realize this by using listeners?

[derekschultz]

I agree with @Gouthamve in that it seems more appropriate to do this via a RunnerListener rather than through a log monitoring mechanism making a request to DB. But, I guess the question with regard to state tracking is where to store state, whether it be in cache or DB. More generally, this is applicable to the whole async functions event lifecycle, which I think needs some further thought.

[seiflotfy]

Agree, sounds like a better way of doing it. Now as Derek mentioned where do we track the state and for how long do we keep the state after completion.

On Fri, Mar 3, 2017 at 11:45 AM Derek Schultz [email protected] wrote:

I agree with @Gouthamve https://github.com/Gouthamve in that it seems more appropriate to do this via a RunnerListener rather than through a log monitoring mechanism making a request to DB. But, I guess the question with regard to state tracking is where to store state, whether it be in cache or DB. More generally, this is applicable to the whole functions event lifecycle, which I think needs some further thought.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iron-io/functions/issues/415#issuecomment-284021353, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHMTWVXrTOfU-XW1iR-M58UGeOy-2mLks5riFG7gaJpZM4LKBUr .

[treeder]

Probably makes sense to store each request in the database along with a state/status column, as @seiflotfy said above.

I think middleware and/or listeners are going to be a great testing/proving ground for a lot of features. Then as they stabilize and/or become something everyone wants, we can make them part of core.