Skip to content

Conversation

scottlovegrove
Copy link
Contributor

@scottlovegrove scottlovegrove commented Dec 3, 2024

Overview

The endpoint we were using for completed tasks is being deprecated and we need to move to a new one.

Initially this would have been to move to archive/items, but this is to be renamed shortly to tasks/archived. I've gone with the latter here, even though it's not live, so this PR can't be merged until this one on the backend has been.

I've also increased the limit to 200, as per the docs of the endpoint to be used to decrease the number of times we may have to call it.

Reference

PR to deprecate the existing endpoint: https://github.com/Doist/Todoist/pull/19393
PR to rename endpoint: https://github.com/Doist/Todoist/pull/19394

Test Plan

  • Run the extension
  • Export a project known to have completed tasks
    • The completed tasks show in the exported google sheet.

@scottlovegrove scottlovegrove self-assigned this Dec 3, 2024
@scottlovegrove scottlovegrove force-pushed the scottl/completed-tasks-api-change branch from ae98783 to 9edf899 Compare December 3, 2024 09:43
@scottlovegrove scottlovegrove force-pushed the scottl/completed-tasks-api-change branch from 9edf899 to 8ea8203 Compare December 3, 2024 10:24
@scottlovegrove
Copy link
Contributor Author

The order in which PRs should be merged are as follows:

  1. PR to rename endpoint (ref)
  2. This PR (once the PR from 1 is deployed)
  3. PR to deprecate old endpoint (ref)

@nats12 I've tagged you in this as the frontend's API update person. If you need assistance to test the PR when (1) has been merged, please speak to Pawel or Francesca, but it should be easy enough to get going.

@PotHix for visibility.

Copy link

@nats12 nats12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@PotHix
Copy link
Member

PotHix commented Dec 3, 2024

  1. PR to deprecate old endpoint (ref)

3 can be merged in any order. The deprecation of the endpoint will only affect new minor versions, and the actual deprecation of v9 will happen ~Q2 2025.

@nats12 I will ping you as soon as the changes are in place. @scottlovegrove will be OOO for holidays soon. :)

@PotHix
Copy link
Member

PotHix commented Jan 7, 2025

An update here, since it's been a month... The change was not that simple, and we couldn't finish it before vacations. I will give it a look in the next few days.

@nats12
Copy link

nats12 commented Jan 8, 2025

cc'ing @pedroalves0 here too from the Transactions squad for visibility.

We are switching to a different completed tasks endpoint in v9.205.

@PotHix
Copy link
Member

PotHix commented Feb 14, 2025

Alright, it took a long time to get back to this one, but here is a summary of what is going to happen:

We are not going to rename archive/items anymore. It is going to stay as is until we find a way to deprecate it. The plan is to rely on tasks/completed/by_completion_date, but it's still not ready for some use-cases. If it's already sufficient for the use-cases of this integration, let's go for it, otherwise, please move to archive/items for now, and discuss this again once we improve /tasks/completed/by_completion_date. 🙇

@scottlovegrove
Copy link
Contributor Author

scottlovegrove commented Feb 14, 2025

Ok, I think we can switch to by_completion_date. We would just need to loop through until we no longer get a cursor, which is essentially what we're doing now with the current code, so shouldn't be a problem.

@pedroalves0 Is this something the transaction squad will be taking care of? Or will it need my intervention to make the changes?

@pedroalves0
Copy link
Member

Ok, I think we can switch to by_completion_date. We would just need to loop through until we no longer get a cursor, which is essentially what we're doing now with the current code, so shouldn't be a problem.

The biggest showstopper of by_completion_date is the fact that it doesn't return recurring tasks completions. Check my post here where I discussed this.
Now, I never used this integration, so if fetching only "real" completed tasks is okay then it's fine to switch to by_completion_date, otherwise tasks/completed has to be used for the moment.

Is this something the transaction squad will be taking care of? Or will it need my intervention to make the changes?

We can offload this PR to the transaction squad, but I can't guarantee that I will look into it any time soon. If you’d like to wrap it up sooner, feel free to implement the changes. Let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants