| << Back to previous view |
|
[QB-2174] REST Query build notifications by statusDate
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 5.1.33 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Lukasz Guminski | Assigned To: | Robin Shen |
| Resolution: | Won't Fix | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
Current REST API for query for build notifications is missing ability to query _incrementally_.
"last_notified_build_id" option is not sufficient, as when you query with e.g "last_notified_build_id=1", you get a list of builds with ids with gaps e.g. 1, 2, 5, and you don't know if builds 3 and 4 haven't yet completed, or you just have access rights to them, and you will never get notification on them. So you don't know if next time you can query with last_notified_build_id=5 (because you will never get notifications about 3 and 4 due to permissions) or you should re-query with last_notified_build_id=1 (because the build are still running) Instead there should last_status_date parameter, so that you could query for all notifications on builds that completed (either successfully or failed depending on your notification settings) after a specified date. |
| Comments |
| Comment by Robin Shen [ 10/Sep/14 01:32 AM ] |
| If users do not have permission to access a build, they should not get the notification. So the incremental search should be working here. |
| Comment by Lukasz Guminski [ 10/Sep/14 09:53 AM ] |
|
Rob, you misunderstood me. I am sorry that I haven't explained the situation clearly.
What you said is true "If users do not have permission to access a build, they should not get the notification." The problem is different. Imagine a situation: User asks for notifications (/notifications?last_notified_build_id=1 ) and gets a response <id>1</id> <id>2</id> <id>5</id> in this moment it is unclear what she should do next. * if next time she will query with last_notified_build_id=5, it might happen that she will miss notifications on builds 3 and 4. It can happen when user has permissions to see 3 and 4, but they completed after build 5. * if instead she decides to keep on querying with last_notified_build_id=1, than it might happen that she will finally get a complete list 1, 2, 3, 4, 5. But it can also happen that user does not have permissions to see 3, 4. So she can query with last_notified_build_id=1 till the end of the world, and she will never get complete list. But she doesn't know that, so he keeps on querying. The first case already shows that incremental querying doesn't work. You can loose notifications with the current approach. Unless I don't understand how it works, which is also possible.. |
| Comment by Robin Shen [ 11/Sep/14 12:53 AM ] |
| QB server will order notifications by the time they happen, instead of by id. So if 3 and 4 finishes after 5, the notification order will be 1 2 5 3 4, so next querying with last_notified_id=5 will get you 3 and 4. |