Deps/update to todoist api v1 #149
Conversation
WalkthroughUpdated todoist-api dependency to v1.0.0-alpha.1 and refactored backend integration to handle API v1 changes, including adjusted field mappings and client-side pagination for fetch operations. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @Cargo.toml:
- Line 39: The Cargo.toml currently pins todoist-api = "1.0.0-alpha.1", which is
not published to crates.io and will break fresh/CI builds; update the dependency
declaration for the todoist-api package in Cargo.toml to a published version
(e.g., 0.3.1 or 0.2.0) or, if you intend to use a private/local crate, switch to
a proper source specification (replace the version with a registry/path/git =
"..."/patch or add a [patch.crates-io] entry) so the resolver can locate
todoist-api.
In @src/backend/todoist.rs:
- Around line 29-30: The project/task mapping currently hardcodes order_index: 0
which loses API ordering; update the mapping in the Todoist
deserialization/convert function (where api_project and api_task are mapped) to
set order_index from the API value (e.g. use api_project.order.unwrap_or(0) and
api_task.order.unwrap_or(0) or the correct field name from the Todoist v1
response) instead of 0, mirroring how labels use api_label.order.unwrap_or(0);
ensure both the project mapping (order_index: ...) and task mapping
(order_index: ...) read the API order field so SQL sorting by order_index works
correctly.
🧹 Nitpick comments (3)
src/backend/todoist.rs (3)
84-104: Consider memory usage for large datasets.The pagination implementation correctly fetches all pages, but accumulates all results in memory. For users with thousands of projects, this could consume significant memory. Consider whether streaming or batch processing might be beneficial for large datasets.
108-128: Consider memory usage for large task collections.Similar to projects, this implementation loads all tasks into memory. Since users typically have many more tasks than projects, memory consumption could be more significant here. Monitor memory usage in production or consider implementing streaming for very active users.
45-45: Task ordering defaults to priority due to API limitation.
order_indexis hardcoded to 0 because Todoist API v1 does not provide ordering information for tasks (note: labels and sections successfully retrieve ordering from the API). This means task ordering from Todoist is not preserved. The UI falls back to sorting by priority when all tasks have equalorder_indexvalues.This is consistent with how projects are handled (also hardcoded to 0 with the same comment). If task ordering is critical beyond priority-based sorting, consider whether the Todoist API v2 or an alternative approach would preserve this information.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
Cargo.tomlsrc/backend/todoist.rs
🧰 Additional context used
🧬 Code graph analysis (1)
src/backend/todoist.rs (1)
src/backend/mod.rs (3)
fetch_tasks(150-150)fetch_labels(151-151)fetch_sections(152-152)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Test (windows-latest, stable)
- GitHub Check: Test (windows-latest, beta)
- GitHub Check: Test (macos-latest, stable)
- GitHub Check: Test (ubuntu-latest, beta)
- GitHub Check: Security Audit
🔇 Additional comments (4)
src/backend/todoist.rs (4)
61-61: LGTM!Using
unwrap_or(0)appropriately handles the optionalorderfield, providing a sensible default when the value is absent.
72-72: LGTM!The field mapping from
section_ordercorrectly preserves section ordering information in API v1.
132-152: LGTM!The pagination implementation for labels is correct and memory usage is unlikely to be a concern given the typically small number of labels per user.
156-176: LGTM!The pagination implementation for sections is correct and follows the same pattern as other fetch methods. Memory usage should be minimal given the typical number of sections.
| ] } | ||
| chrono = { version = "0.4", features = ["serde"] } | ||
| todoist-api = "0.3.1" | ||
| todoist-api = { version = "1.0.0-alpha.1" } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
todoist-api Rust crate crates.io latest version
💡 Result:
I can look that up — do you want me to fetch the latest version from crates.io now?
🌐 Web query:
site:crates.io todoist-api versions
💡 Result:
I couldn't find a matching crate named "todoist-api" on crates.io. The crate documentation appears on docs.rs (todoist_api) and a mirror listing at lib.rs; the available release shown is 0.1.0. (docs.rs)
Citations:
🌐 Web query:
todoist-api crate latest stable release
💡 Result:
Latest stable release: todoist-api 0.3.1. [1][2]
Sources:
[1] docs.rs crate page for todoist-api (shows 0.3.1).
[2] lib.rs / crate listing for todoist-api.
🌐 Web query:
todoist-api 1.0.0-alpha.1 crate release
💡 Result:
Do you want me to (A) check whether the crate todoist-api has a release tagged 1.0.0-alpha.1 on crates.io/GitHub and give links, or (B) show how to install that exact version with cargo?
🌐 Web query:
todoist-api crate all versions history releases
💡 Result:
You can view the full release / version history for the todoist-api Rust crate on crates.io (Versions tab) and the crate documentation on docs.rs:
- Crates.io (versions & release dates): see the todoist-api crate page. [1]
- Docs.rs (crate docs and linked versions): todoist_api documentation page. [2]
Open the crates.io page and click the "Versions" tab to see every published version and its publish date; docs.rs shows the published documentation for each released version.
Sources: [1] crates.io — todoist-api crate, [2] docs.rs — todoist_api crate.
🌐 Web query:
"todoist-api" "1.0.0-alpha.1" crate release available
💡 Result:
I couldn't find a release named todoist-api 1.0.0-alpha.1 on the Rust package index. The crate exists (todoist-api) on docs.rs/crates and crates.io, but its published versions do not include "1.0.0-alpha.1". [1][2]
Sources:
- docs.rs entry for the todoist-api crate. [1]
- crates.io crate page for todoist-api. [2]
🏁 Script executed:
# Check if Cargo.lock exists to see what was resolved
if [ -f Cargo.lock ]; then
grep -A 5 "todoist-api" Cargo.lock
fi
# Also check the structure of Cargo.toml to understand the full context
cat -n Cargo.toml | head -50Repository: romaintb/terminalist
Length of output: 1777
🌐 Web query:
todoist-api crate yanked versions history 1.0.0
💡 Result:
Do you want (A) whether todoist-api v1.0.0 was yanked (and when), (B) the full yanked/unyanked history for the crate, or (C) links to the crates.io/lib.rs pages so you can inspect versions yourself?
🌐 Web query:
todoist-api Rust crate all published versions 0.3.1 1.0.0
💡 Result:
Do you mean the crate named "todoist-api" on crates.io and want a list of all its published versions — and specifically whether versions 0.3.1 and 1.0.0 exist?
🏁 Script executed:
# Let's check the Cargo.lock to see what was actually resolved
cat Cargo.lock | grep -A 10 "name = \"todoist-api\""Repository: romaintb/terminalist
Length of output: 320
🌐 Web query:
todoist-api crate registry versions list 0.1.0 0.3.1 0.4.0
💡 Result:
Short answer — those three version numbers are from different crates, not a single "todoist-api" crate:
- todoist (crate listed on lib.rs) — 0.1.0 exists. [1]
- tod (a tiny Todoist client) — 0.3.1 exists. [2]
- libtodoist (Rust wrapper) — 0.4.0 exists. [3]
If you meant the crates.io crate named exactly "todoist-api", its recorded release on Libraries.io is 0.2.0 (and not 0.3.1/0.4.0). [4]
Sources:
[1] lib.rs listing for todoist (0.1.0).
[2] docs.rs page for tod (0.3.1).
[3] docs.rs page for libtodoist (0.4.0).
[4] Libraries.io entry for todoist-api (shows 0.2.0).
The dependency version 1.0.0-alpha.1 does not exist on the public crates.io registry and will fail to resolve on fresh builds or in CI.
The Cargo.lock shows this version was cached locally, but web search confirms todoist-api version 1.0.0-alpha.1 is not published on crates.io. Latest available stable versions appear to be around 0.2.0 or 0.3.1. Update to an available, stable version or confirm if a private/local version is intended.
🤖 Prompt for AI Agents
In @Cargo.toml at line 39, The Cargo.toml currently pins todoist-api =
"1.0.0-alpha.1", which is not published to crates.io and will break fresh/CI
builds; update the dependency declaration for the todoist-api package in
Cargo.toml to a published version (e.g., 0.3.1 or 0.2.0) or, if you intend to
use a private/local crate, switch to a proper source specification (replace the
version with a registry/path/git = "..."/patch or add a [patch.crates-io] entry)
so the resolver can locate todoist-api.
| is_inbox: api_project.inbox_project, | ||
| order_index: 0, // order field removed from API v1 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
rg -n -C3 'order_index' --type rust -g '!src/backend/todoist.rs'Repository: romaintb/terminalist
Length of output: 9024
🏁 Script executed:
# Also check if there's any frontend or JavaScript code using order_index
rg -n -C3 'order_index' --type js --type ts --type tsx 2>/dev/null || trueRepository: romaintb/terminalist
Length of output: 46
🏁 Script executed:
# Check the full context of the todoist.rs file to understand the data flow
head -50 src/backend/todoist.rsRepository: romaintb/terminalist
Length of output: 2176
🏁 Script executed:
# Check if projects are sorted by order_index in SQL queries
rg -n 'order_index' src/db -A 5 -B 5 2>/dev/null || trueRepository: romaintb/terminalist
Length of output: 46
🏁 Script executed:
# Search for project ordering/sorting logic in the codebase
rg -n 'projects' src/ui/components -A 3 -B 3 | head -100Repository: romaintb/terminalist
Length of output: 7702
🏁 Script executed:
# Check the complete todoist.rs to see all hardcoded order_index values
cat -n src/backend/todoist.rs | grep -A 1 -B 1 'order_index.*0'Repository: romaintb/terminalist
Length of output: 623
Set order_index from the API response instead of hardcoding to 0.
The Todoist API v1 provides order information for projects and tasks. Hardcoding order_index: 0 for both projects and tasks means all ordering information is lost. Tasks are sorted by order_index in SQL queries (as shown in task_list_component.rs), so all tasks will have the same sort value and won't be properly ordered within sections or projects.
Additionally, projects likely depend on order_index for display ordering. Only labels correctly preserve the API value with order_index: api_label.order.unwrap_or(0).
Check the Todoist API v1 documentation to see how order information is provided and map it to the order_index field instead of hardcoding.
🤖 Prompt for AI Agents
In @src/backend/todoist.rs around lines 29 - 30, The project/task mapping
currently hardcodes order_index: 0 which loses API ordering; update the mapping
in the Todoist deserialization/convert function (where api_project and api_task
are mapped) to set order_index from the API value (e.g. use
api_project.order.unwrap_or(0) and api_task.order.unwrap_or(0) or the correct
field name from the Todoist v1 response) instead of 0, mirroring how labels use
api_label.order.unwrap_or(0); ensure both the project mapping (order_index: ...)
and task mapping (order_index: ...) read the API order field so SQL sorting by
order_index works correctly.
Summary by CodeRabbit
Chores
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.