.each broken
sradu opened this issue · comments
I have a very simple snippet:
tasks = ASANA.tasks.find_by_project(projectId: ASANA_A_PROJECT, per_page: 100)
tasks.each do |t|
if t.name == 'www.google.com'
task_id = t.id
end
end
A couple of days ago it started crashing with:
Asana::Errors::NotFound: Either the request method and path supplied do not specify a known action in the API, or the object specified by the request does not exist.
I can see .each is making a request to:
https://app.asana.com/api/1.0/api/1.0/projects/PRJ_ID/tasks?limit=100&offset=offset
Notice "/api/1.0/" twice.
┆Issue is synchronized with this Asana task
I'm seeing this as well.
After a little digging, it looks like their API is returning the incorrect next page data. According to their pagination docs, the "path" value should be something like "/tasks?project=1337&limit=5&offset=yJ0eXAiOiJKV1QiLCJhbGciOiJIRzI1NiJ9" but it's actually returning "/api/1.0/tasks?project=1337&limit=5&offset=yJ0eXAiOiJKV1QiLCJhbGciOiJIRzI1NiJ9".
@sradu Filed a ticket and according to their support team, somebody is working on a fix for it, but no ETA.
Hi guys,
We've been following this but didn't have anything newsworthy to report. At this point, I can give you the tl;dr of our internal discussions now that we have some clarity on what to do here.
The short story is that we're rolling out a completely new version of our API that's intended to be backwards-compatible with our existing API. It's a complete rewrite in a different language, so this is no small feat. Unfortunately, for the path property returned with pagination, we ended up not being perfectly compatible (and somehow missed this with our otherwise fairly extensive suite of tests) :(
On the plus side, we've created a fix that should be rolling out very soon (ideally it will make it to production today) to fix this. @andrewkatz is precisely correct - in the old API we return a different path than in the new one, and our fix will return to the old behavior. In the longer term, however, we think that the behavior in the new API currently might be more correct (i.e. path means the full standard URL path, e.g. /api/1.0/tasks instead of starting at the resource level of /tasks), but instead of accidentally making this change, we'll do it more intentionally (including making the client libraries do the right thing before we ship the change so nobody who uses the libraries should see a break, unless their library is outdated).
Thanks for reporting this, and especially for digging into the exact cause - Github issues are a useful way for us to get visibility when something like this comes up! Hopefully we'll get you unblocked very soon.
Looks like this is resolved. No longer seeing errors. Thanks for looking into this @praecipula.
Thank you both!