Issue Summary

The UI (and REST API) can miss returning webhooks.

The Webhooks UI page uses an infinite scroll, and behind the scenes it makes requests in pages of size 25. In order to build a page of results Bitbucket queries the database with limit 26, in order to decide if the page is the last page or not. The result set returns the first 25 rows, as requested.

The problem is the final query that returns the results is of the form:

SELECT * FROM "AO_A0B856_WEBHOOK" WHERE "ID" IN (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26)

The numbers are webhook ID's obtained in an earlier query. The problem is there is no "ORDER BY" clause and as a result the order is not deterministic. In the case of PostgreSQL, at least in the situation where this problem was found, the ordering meant the webhook row that was updated last is returned in the 26th position. This then becomes the row that is dropped.

So in paging, in addition to the missing row, the page happens to include a row that should be in the subsequent page. It however doesn't get duplicated in the UI when the subsequent page is fetched; the UI does de-duplication.

Steps to Reproduce

1. Create 30 webhooks named "Webhook 1" thru "Webhook 30"
2. Observe all 30 webhooks are visible in the UI
3. Edit the URL for "Webhook 15"

Expected Results

All 30 webhooks should be visible in the UI

Actual Results

Only 29 webhooks are visible in the UI. Webhook 15 is missing

Workaround

If you know the webhook ID, you can navigate to the webhook details page by URL hacking