Updating Task detail after create causes error - Microsoft Planner API

Question

I have been using Microsoft Graph planner API to push previously created planner (sort of like a template) to newly created planner ( the feature was in the works but I couldn't wait for it to roll over on who knows when),

so i created simple web application(Nodejs) that just pushes template on to the new planner.

currently the flow is planner created -> bucket created -> task created -> get task detail ( to make sure the task exists) -> update task detail (check boxes).

however request "get task detail" right after creating it causes 404 error

{ error: { code: "", message: "The requested item is not found.", innerError: { "request-id": "...", date: "..." } } }

I've originally skipped the "get task detail" but that often caused 412 "if match cannot be found error"

the web application WAS working (no changes was pushed for couple of months actually).

Currently, trying the "get task detail" after couple of minutes works perfectly fine.

I can only assume that it now takes longer for task to be created which causes this error, but I cant make the user sit idle for couple of minutes for this to finish.

any idea would be greatly appreciated.

thank you.

Answer 1

The operation execution is asynchronous, and sometimes the operations can take a bit of time to complete. You need to read the task details to be able to update it, since PATCH operation requires client's last known etag to be passed in with If-Match header. There are a few different improvements in the pipe to improve this scenario on the service side, which should automatically improve the reliability.

You've mentioned your scenario is creating a new plan from a template plan, which should require a number of tasks to be created. Based on your description, I'm assuming you create a task then update the details of that task before moving on to the next task. If you change the order such that you create all tasks before updating any of their details, the service would have more time to finish the asynchronous operation before you get to detail updates. You'll still need to retry the read to be sure.

I know this is not really a solution, but this approach should make the user experience a bit better until the service behavior improves.

Answer 2

The problem is that when you send your initial request to create a new Task, the Task Details Instance was never created yet, it's an async process.

With flow I added the delay step for 5 seconds.

With Graph API i added a loop to keep trying until i get the glorious 200 OK

getDetails(taskID:string) : Observable<MicrosoftGraph.PlannerTaskDetails> {

    let u = 'planner/tasks/' + taskID + '/details';

    let s = new Subject<MicrosoftGraph.PlannerTaskDetails>();

    let stamp = function stamp(){
        let d = new Date();
        return '[ss:ms][' + d.getSeconds() + '-' +  d.getMilliseconds() + ']';
    }

    let askDetails = () => {
        let detailsAjaxObs = this.getData<MicrosoftGraph.PlannerTaskDetails>(u, null, true);
        detailsAjaxObs.delay(650).subscribe(
            details => {
                console.log('getDetails => getData <PlannerTaskDetails> , s.next(details) ' + stamp());
                s.next(details);
            },
            err => {
                console.info('getDetails => getData <PlannerTaskDetails> err, trying again | ' + stamp());
                console.info(err);
                askDetails();
                //s.error(err);
                //error "kill" the objs just like complete
            }
        );
    };

    askDetails();

    return s.asObservable();
} // end getDetails

I think today I would've changed the delay to just 5000, at this app I wanted fast as possible results and didnt care for un-needed requests. Also stamp is just for logging, you can remove it and the logs.