If I have a since_id of a post which got deleted, the server seems just to ignore the calls. That leads to the fact that TentStatus never will show "1 New Post" again until you reload the page.
I think this one is a critical bug, in TentStatus you only have to reload the page, in Tentia you have to restart it (because then it fetches the 200 newest without a since_id) but for example in Bivy (and I assume in the other mobile clients too) you need to remove the app and its database, reinstall it so it can start fresh without a since_id.
What is the behaviour of the server when the since_id doesn't exist?
Then the server returns 304 Not Modified
Ah, that is a serious bug, we'll look into it.
the bug is in one of the sql query's generated for since_id
I, [2012-12-20T23:38:18.300241 #28055] INFO -- : (0.000561s) SELECT "id", "public_id", "entity" FROM "posts" WHERE (("deleted_at" IS NULL) AND ("user_id" = 1) AND ("public_id" IN ('kk6hqn')))
this works fine when deleted_at is actually null however when the post matching public_id gets deleted the deleted_at is no longer null and obivously the sql query does not return anything, this causes tentd to think there have been no new posts
This should result in something like a 400 when the since_id doesn't exist, I think.
returns 200 on my tentd
GET /posts?since_id=kk6hqn HTTP/1.0
Accept-Encoding: gzip, deflate, compress
User-Agent: python-requests/0.14.2 CPython/2.7.3
HTTP/1.0 200 OK
Cache-Control: max-age=0, private, must-revalidate
I still would like the behaviour which was there in v0.1 where I got all posts which arrived after that, even the deleted-post-type notification so I can remove this post in my client. With a 400 I would have to find some older id which I then could use for getting everything which happened after it.
the same query returns the expected result if i knock out the deleted_at but gives the above result as soon I as replace it
@jeena I was thinking in the more general case of a since_id not existing. In this case we can make it work as you'd expect, by ignoring the deleted_at column.
Fix: id lookup disregards deleted_at
56947b3 fixes this