User unexpectedly receives a 404 when attempting to fetch a task that does exist

[coddingtonbear]

[07:32:46] Lynoure Hi, I am moving from the inthe.am build-in taskserver to my own. Is there something that needs to be done to allow this transition on my server, or on the inthe.am site?  My settings are such that work with taskwarrior on my laptop and Mirakel on my Android.
[07:40:07] Lynoure Ah, got it.
[07:45:53] Lynoure Is the slowness of inthe.am server resource related or software related? That is, would it be preferrable if I set up a intheam server of my own?
[07:47:15] @coddingtonbear hey there Lynoure
[07:47:41] @coddingtonbear what's this slowness you're referring to -- do you mean in sync operations, UI, or...?
[07:49:21] Lynoure UI
[07:51:26] @coddingtonbear hrm, I have no idea, actually -- the only view that takes longer than 500ms to load for me is the main tasks view, and that's still under 1s; how slow, and which view, Lynoure ?

---
[08:00:21] Lynoure The main list view for me takes always multiple seconds, about 10s, I think.
[08:24:48] @coddingtonbear ahh, interesting -- I had no idea it could take that long; how many tasks do you have in your pending task list?
[08:35:50] Lynoure 168
[08:37:44] @coddingtonbear hrm, that's not enough that it should take that long
[08:50:48] Lynoure I don't know how to send you the timeline I get out of Chromium.
[08:54:58] Lynoure and I don't have time do further troubleshooting today. Some of the images arrive only at ~3s, and then they get reloaded again as a result of some event?
[08:56:18] Lynoure There are also some 404s that take a while.
[08:57:02] @coddingtonbear interesting -- there are only a couple images on the whole site; I think the logo might be the only one off of the /about/ page
[08:58:05] Lynoure one of them: http://sentry.adamcoddington.net/api/2/store/?sentry_version=4&sentry_client=raven-js/1.1.10&sentry_key=9b0ea040d8414b2180548e304cac5018&sentry_data=%7B%22project%22%3A%222%22%2C%22logger%22%3A%22javascript%22%2C%22platform%22%3A%22javascript%22%2C%22request%22%3A%7B%22url%22%3A%22https%3A%2F%2Finthe.am%2Ftasks%2F6ef87bb9-df50-4a45-95fd-6acbd790b3ca%22%2C%22headers%22%3A%7B%22User-Agent%22%3A%22Mozilla%2F5.0%20(X11%3B%20Linux%20x86_64)%20Apple
[08:58:20] Lynoure oops, that's a bit long. :)
[09:03:00] @coddingtonbear oh, neat -- so it's trying to report an error
[09:04:07] @coddingtonbear I think that might be the problem
[09:04:12] @coddingtonbear http://sentry.adamcoddington.net/the-proletariat/in-the-am/group/343/
[09:04:50] @coddingtonbear in the private view, it shows that those are from your account; that's probably the reason it's slow for you
[09:05:01] @coddingtonbear it's reporting hundreds of errors every time you load the tasks view
[09:06:08] @coddingtonbear it looks like the root of it is that it's trying to fetch task details for tasks that don't appear to exist, which is interesting; http://sentry.adamcoddington.net/the-proletariat/in-the-am/group/379/
[09:06:08] Lynoure Given that every couple of minutes it tries again, probably endless amount? (I have not yet looked at the sources, just at the timeline)
[09:06:39] @coddingtonbear it's probably from loading task dependencies, but I'll have to do a little digging
[09:06:44] @coddingtonbear brb in 1h
[09:06:49] Lynoure No hurry
[09:07:14] Lynoure I'll be out of the door in an hour myself. (And this has been interesting/inspiring/fun)
[09:08:41] Lynoure ...and back only tomorrow.

---
[18:59:50] @coddingtonbear I've just now made a couple little changes to inthe.am -- one of which will prevent it from trying to report an error when a task 404s; when you get a chance, could you see if the loading time improves for you, Lynoure?

---
[23:37:09] @coddingtonbear thinking it through, I'm not sure if my changes will help, but i'd be interested to hear about any differences anyway, Lynoure  :-)

---
[07:41:49] Lynoure coddingtonbear: There was some improvement, noticeable even, but it's still interesting in the chinese way
[07:42:00] Lynoure coddingtonbear: no longer 404s, now 400s instead =)
[07:42:03] @coddingtonbear haha
[07:42:04] @coddingtonbear well, hrm
[07:42:34] Lynoure coddingtonbear: Don't get stressed over this, this is most fun I have had with computers for couple of weeks :)
[07:42:49] @coddingtonbear heh, interesting
[07:43:01] @coddingtonbear well, it looks like it's trying to fetch the task with the ID of 794d2195-f1b4-4c8c-85d6-56cda34a38f4
[07:43:03] Lynoure You know, all the joy of casual "oh, I wonder", without any feeling of "I must" or even "I broke it" =)
[07:43:51] @coddingtonbear haha, well, no -- if you broke it, it's my fault for not putting in the appropriate guardrails
[07:43:59] @coddingtonbear so, I'm interested in trying to figure out what might be going wrong
[07:44:26] Lynoure there are 400s for various task ids, if I am reading the urls right... about a dozen of them.
[07:44:56] @coddingtonbear so, can you run `task all 794d2195-f1b4-4c8c-85d6-56cda34a38f4` from the commandline and tell me if you see a result?
[07:46:30] @coddingtonbear yeah -- I only looked through the first couple of error reports and saw that those matched the URL; there very well could be other IDs down there
[07:47:24] @coddingtonbear and if you don't see any results from `task all 794d2195-f1b4-4c8c-85d6-56cda34a38f4`, do you see any if you run `task all depends:794d2195-f1b4-4c8c-85d6-56cda34a38f4`?
[07:48:23] Lynoure yes, that task exists, and is pending, even.
[07:48:51] Lynoure (and one of the things on my short list for today)
[07:49:28] @coddingtonbear interesting
[07:49:35] @coddingtonbear hrm -- that's not the answer I was expecting
[07:50:39] Lynoure Is it possible that despite discarding all the data before switching to using my own taskserver, something broke anyway?
[07:51:15] Lynoure this is one of the tasks added recently enough...
[07:51:56] @coddingtonbear yeah
[07:52:01] @coddingtonbear well -- i'm mystified
[07:52:11] @coddingtonbear but I think i have enough information to keep looking after I'm done with work for the day

Repo SHA: 7264d56e0ebd4b0dc4e92fa22d1418636a9d01f5.

[coddingtonbear]

Whee! Finally somebody else has came across the issue, and I should now have enough information to be able to get digging --

Private error link: http://sentry.adamcoddington.net/the-proletariat/in-the-am/group/531/

[coddingtonbear]

Unfortunately, that seems to be a dead-end; I'll just need to wait for somebody else to bump into this, I'm afraid to say.

[coddingtonbear]

I think what was happening before was that, during a sync we'd see changed tasks (read: created tasks) appearing, and the event indicating to the client that a new task appeared would make it to the client before the sync operation had completed.

Now, all operations involving mutating the task list should be gated behind a lock; I think that solves this one.