Notification API bugs. #5692

New Issue

GiteaMirror · 2025-11-02T06:33:18-06:00

GiteaMirror commented

2025-11-02 06:33:18 -06:00

Originally created by @ghost on GitHub (Jul 5, 2020).

Gitea version (or commit ref): 1.13.0+dev-218-gec40e593c
Git version: N/A
Operating system: N/A
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
- N/A
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
- Tried at gitea.com
Log gist:

Description

There are two major bugs when trying to load a selection of notifcations using the API. These bugs were already confirmed by @6543.

1. Bug

From what I've seen, any request with all=true leads to an internal server error (Response code: 500).

2. Bug

Any pinned notifications are not included in the results.

Screenshots

Originally created by @ghost on GitHub (Jul 5, 2020). - Gitea version (or commit ref): 1.13.0+dev-218-gec40e593c - Git version: N/A - Operating system: N/A - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - [x] N/A - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - [x] Tried at [gitea.com](https://gitea.com/) - Log gist: ## Description There are two major bugs when trying to load a selection of notifcations [using the API](https://gitea.com/api/swagger#/notification/notifyGetList). These bugs were already confirmed by @6543. ### 1. Bug From what I've seen, any request with ``all``=true leads to an internal server error (Response code: 500). ### 2. Bug Any pinned notifications are not included in the results. ## Screenshots

GiteaMirror added the modifies/api label 2025-11-02 06:33:18 -06:00

GiteaMirror closed this issue

2025-11-02 06:33:18 -06:00

GiteaMirror commented

2025-11-02 06:33:19 -06:00

@zeripath commented on GitHub (Jul 5, 2020):

Hi!

I can't seem to reproduce this.

curl -u user:password 'localhost/gitea/api/v1/notifications?all=true' seems to work for me and it gives the pinned results too.

@zeripath commented on GitHub (Jul 5, 2020): Hi! I can't seem to reproduce this. `curl -u user:password 'localhost/gitea/api/v1/notifications?all=true'` seems to work for me and it gives the pinned results too.

GiteaMirror commented

2025-11-02 06:33:19 -06:00

@ghost commented on GitHub (Jul 5, 2020):

Hi, this is weird. With which version of Gitea did you test your request and did you try the same on gitea.com?

@ghost commented on GitHub (Jul 5, 2020): Hi, this is weird. With which version of Gitea did you test your request and did you try the same on gitea.com?

GiteaMirror commented

2025-11-02 06:33:19 -06:00

@zeripath commented on GitHub (Jul 5, 2020):

I tested this on master right now

@zeripath commented on GitHub (Jul 5, 2020): I tested this on master right now

GiteaMirror commented

2025-11-02 06:33:20 -06:00

@ghost commented on GitHub (Jul 5, 2020):

curl -X GET "https://gitea.com/api/v1/notifications?all=false&since=2003-02-22T00%3A00%3A00%2B00%3A00&page=1&limit=50" -H  "accept: application/json" -H  "Authorization: token censored"

The upper call works for me, but this one does not:

curl -X GET "https://gitea.com/api/v1/notifications?all=true&since=2003-02-22T00%3A00%3A00%2B00%3A00&page=1&limit=50" -H  "accept: application/json" -H  "Authorization: token censored"

@ghost commented on GitHub (Jul 5, 2020): ``` curl -X GET "https://gitea.com/api/v1/notifications?all=false&since=2003-02-22T00%3A00%3A00%2B00%3A00&page=1&limit=50" -H "accept: application/json" -H "Authorization: token censored" ``` The upper call works for me, but this one does not: ``` curl -X GET "https://gitea.com/api/v1/notifications?all=true&since=2003-02-22T00%3A00%3A00%2B00%3A00&page=1&limit=50" -H "accept: application/json" -H "Authorization: token censored" ```

GiteaMirror commented

2025-11-02 06:33:20 -06:00

@ghost commented on GitHub (Jul 5, 2020):

I've also tested this directly using the built in swagger documentation of gitea.com. Same results:

@ghost commented on GitHub (Jul 5, 2020): I've also tested this directly using the built in [swagger documentation](https://gitea.com/api/) of gitea.com. Same results: ![grafik](https://user-images.githubusercontent.com/64696032/86541062-1cae8900-bf0a-11ea-933f-c52b3cb2ca3b.png)

GiteaMirror commented

2025-11-02 06:33:20 -06:00

@zeripath commented on GitHub (Jul 5, 2020):

master is v1.13.0-dev-276-g217647f33 - I guess this might already be fixed.

@zeripath commented on GitHub (Jul 5, 2020): master is v1.13.0-dev-276-g217647f33 - I guess this might already be fixed.

GiteaMirror commented

2025-11-02 06:33:20 -06:00

@ghost commented on GitHub (Jul 5, 2020):

Okay. Then I apologize for the inconvenience. I will now run the same query on the latest version of Gitea and will inform you if there are still issues.

@ghost commented on GitHub (Jul 5, 2020): Okay. Then I apologize for the inconvenience. I will now run the same query on the latest version of Gitea and will inform you if there are still issues.

GiteaMirror commented

2025-11-02 06:33:20 -06:00

@ghost commented on GitHub (Jul 5, 2020):

Okay, i can confirm that the notifications API in 1.13.0+dev-275-g0d03fbf2c works so far. But I wonder why pinned notifications can only be seen when all is true. Is this behavior expected, and if so, why is it not mentioned in the documentation?

@ghost commented on GitHub (Jul 5, 2020): Okay, i can confirm that the notifications API in ``1.13.0+dev-275-g0d03fbf2c`` works so far. But I wonder why pinned notifications can only be seen when ``all`` is true. Is this behavior expected, and if so, why is it not mentioned in the documentation? ![grafik](https://user-images.githubusercontent.com/64696032/86541636-bc6e1600-bf0e-11ea-90e9-7af8fd08cd0f.png)

GiteaMirror commented

2025-11-02 06:33:21 -06:00

@zeripath commented on GitHub (Jul 5, 2020):

Oh I see what you mean - I think this API is slightly poorly written.

Ok we need these to return pinned and unread by default.

@zeripath commented on GitHub (Jul 5, 2020): Oh I see what you mean - I think this API is slightly poorly written. Ok we need these to return pinned and unread by default.

GiteaMirror commented

2025-11-02 06:33:21 -06:00

@ghost commented on GitHub (Jul 5, 2020):

That would be great! Thanks a lot for your help!

@ghost commented on GitHub (Jul 5, 2020): That would be great! Thanks a lot for your help!

GiteaMirror commented

2025-11-02 06:33:21 -06:00

@6543 commented on GitHub (Jul 8, 2020):

I think this API is slightly poorly written.

@zeripath It just imitates github ones - and yes I missed pined one somehow :/

@6543 commented on GitHub (Jul 8, 2020): > I think this API is slightly poorly written. @zeripath It just imitates github ones - and yes I missed pined one somehow :/

GiteaMirror commented

2025-11-02 06:33:21 -06:00

@zeripath commented on GitHub (Jul 8, 2020):

@6543 sorry poor choice of words.

The issue with pinned is that it doesn't quite match with GitHub's saved notifications - so there is always going to be a slight inconsistency. I guess given we have a pinned status rather than saved it's probably best to just show the pinned ones by default.

TBH I've only really understood the pinned notifications since messing around with the event source - I would have forgotten about the pinned ones too!

@zeripath commented on GitHub (Jul 8, 2020): @6543 sorry poor choice of words. The issue with pinned is that it doesn't quite match with GitHub's saved notifications - so there is always going to be a slight inconsistency. I guess given we have a pinned status rather than saved it's probably best to just show the pinned ones by default. TBH I've only really understood the pinned notifications since messing around with the event source - I would have forgotten about the pinned ones too!

GiteaMirror commented

2025-11-02 06:33:21 -06:00

@zeripath commented on GitHub (Jul 8, 2020):

The issue is that the plain GH API doesn't quite match what we have, (and doesn't match theirs either tbh) so in that sense it's a poor API that's too simplistic. However it appears simple to extend so as long as we can do that sensibly that's fine.

@zeripath commented on GitHub (Jul 8, 2020): The issue is that the plain GH API doesn't quite match what we have, (and doesn't match theirs either tbh) so in that sense it's a poor API that's too simplistic. However it appears simple to extend so as long as we can do that sensibly that's fine.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#5692