Satnogs-monitor no longer running on any PC, are there network problems?
I can confirm that it is seemingly not working any more, from a station where I have been using it recently.
Recently due to performance issues, there was a change on the observations API pagination. Instead of using the pages pagination it uses cursor pagination.
The next page link, to move to the next page of results is available in the standard response header Link, so a program that uses the API, should use this way to navigate through the pages.
In this part of the code we can see that satnogs-monitor doesn’t use the Link header but iterates infinitely the page parameter, in other words to move on the next page it adds in the url this parameter ?page=x where x is replaced each time with a page number. Unfortunately this way doesn’t work any more.
The way it is implemented uses two ways to break the infinite loop, the one is by getting a page with less than 25 results, which would mean that this is the last page. The other is by getting a 404 error, that the page doesn’t exist. With the current status, the ?page=x parameter is ignored with any value for x and returns always the first page. This means that it will never hit 404 error and if the station has more than 25 past observations, it will never hit the less than 25 results break. So it looks like it remains in the infinite loop and this is why you don’t see any results.
Unfortunately I’m not very fluent in Rust language so I can not propose a solution and from the comment in the code:
// We cannot use the response headers to know if there is next page with more
// results. So we iterate over every page and stop if we receive an HttpError 404.
I’m not sure how easy would be a code change to use the response headers and especially the Link header that will allow navigation through the pages.
@wose maybe can take a look on it.
PS above is my guess of what looks like to be the issue, maybe there is another issue that I haven’t spotted
Thank you for the quick reply, it’s strange because on the same PC I have 2 simultaneous sessions as you can see from the following link SatNOGS Network - User: ik1jns , and the second session on ID=3523 works, it seems only the first on ID=446 I have this problem and with netstat I have this result while with the second session it works normally.
1 Like
hm… maybe then it filters the observations API endpoint to show only the future observations. In this case the station with ID 3523, that has less than 25 future observations, it will hit the break and will get out of the infinite loop, while station 446 with 25 future observations will stay forever in it.
Unfortunately I can not check the above right now as I’m on mobile but I’ll try to take a look later today. By the way if only the future observations are necessary, I suggest it should hit the jobs API endpoint which returns only the future observations and without pagination.
However maybe the project uses some fields from observation entry that are not exposed in jobs entries, in this case and if the access to the response header is not possible, I suggest it should get the observations from the jobs API and then using the observation IDs, hit the observations API endpoint with filtering with 25 IDs each time (to limit it to only one page) to get the extra info. For the filtering it needs the parameter ?observation_id= and as value the observations IDs separated by commas, for example ?observation_id=9319687,9319686.
Thanks for the help, I solved it, I was wrong when entering endpoint api, now by entering the correct command it works. I was deceived by having 2 IDs and on one it worked and the other didn’t, as you rightly noticed, the first is 5 years old and therefore many more registrations, the second is new and has few registrations. The other reason is that until a few days ago it always worked. Sorry for wasting your time, but I think this topic could be helpful to others too. Thank you
right command
