API pagination changes when closing issues #3865

New Issue

GiteaMirror · 2025-11-02T05:28:51-06:00

GiteaMirror commented

2025-11-02 05:28:51 -06:00

Originally created by @bobemoe on GitHub (Aug 28, 2019).

I'm using the API to loop through all open issues, and due to the pagination I have to do this one page at a time, which is fine, until my script closes one of the issues on the current page, after this has happened, when the next page is requested, an issue is missing, because it has moved onto the previous page to take the place of the closed issue.

Is there a way to avoid this?

Could we get a token that stops the data set changing while we loop through the pages maybe?

Otherwise I could account for this in my script, but none of my ideas here seem very elegant or efficient for large numbers or issues:

I could:

Load all pages into memory before beginning processing.
Request each page multiple times until nothing has changed.
Not actually close issues, but keep a record of them and close them all at the end of the loop.

Any thoughts much appreciated :)

Originally created by @bobemoe on GitHub (Aug 28, 2019). I'm using the API to loop through all open issues, and due to the pagination I have to do this one page at a time, which is fine, until my script closes one of the issues on the current page, after this has happened, when the next page is requested, an issue is missing, because it has moved onto the previous page to take the place of the closed issue. Is there a way to avoid this? Could we get a token that stops the data set changing while we loop through the pages maybe? Otherwise I could account for this in my script, but none of my ideas here seem very elegant or efficient for large numbers or issues: I could: * Load all pages into memory before beginning processing. * Request each page multiple times until nothing has changed. * Not actually close issues, but keep a record of them and close them all at the end of the loop. Any thoughts much appreciated :)

GiteaMirror added the type/question label 2025-11-02 05:28:51 -06:00

GiteaMirror closed this issue

2025-11-02 05:28:51 -06:00

GiteaMirror commented

2025-11-02 05:28:52 -06:00

@guillep2k commented on GitHub (Aug 28, 2019):

Not actually close issues, but keep a record of them and close them all at the end of the loop.

IMHO this should be the way to do this.

@guillep2k commented on GitHub (Aug 28, 2019): > * Not actually close issues, but keep a record of them and close them all at the end of the loop. IMHO this should be the way to do this.

GiteaMirror commented

2025-11-02 05:28:52 -06:00

@lunny commented on GitHub (Aug 29, 2019):

You have to store all needes issue index when you traversing the issues. And then close them.

@lunny commented on GitHub (Aug 29, 2019): You have to store all needes issue index when you traversing the issues. And then close them.

GiteaMirror commented

2025-11-02 05:28:52 -06:00

@bobemoe commented on GitHub (Aug 29, 2019):

Thanks for confirming that I'm not missing some built in technique. I guess that was my main concern.

My reluctance to do this is that my script uses an OO model to represent the data, and storing just the ID breaks that a bit. I could store the whole object, but I'm working with a large number of issues and wanted to only have one in memory at a time, but it sounds like this is the way to go. Thanks for the advice.

Maybe I'll implement some sort of write cache similar to MySQL transactions. Memory is cheap these days ;)

@bobemoe commented on GitHub (Aug 29, 2019): Thanks for confirming that I'm not missing some built in technique. I guess that was my main concern. My reluctance to do this is that my script uses an OO model to represent the data, and storing just the ID breaks that a bit. I could store the whole object, but I'm working with a large number of issues and wanted to only have one in memory at a time, but it sounds like this is the way to go. Thanks for the advice. Maybe I'll implement some sort of write cache similar to MySQL transactions. Memory is cheap these days ;)

GiteaMirror referenced this issue

2025-11-02 12:32:31 -06:00

[PR #4293] [CLOSED] ignore ca warning #17320

GiteaMirror referenced this issue

2025-11-02 12:32:32 -06:00

[PR #4296] [MERGED] Remove call to update certs #17321

Sign in to join this conversation.