[Feature Request] API Hook for Date/Time Interval Retrieval of Messages
Los mantenedores suelen responder en 2 días
@eternal-flame-AD ya está trabajando en esto.
Desde el 9/12/2025.
- #890 de @eternal-flame-AD — abierto
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Hi!
I am one of the developers working on Winify, a graphical UI client for Windows and one of the features that we implement is the retrieval of past notifications between a certain time-interval.
The problem is that there is no direct API hook to do that directly via Gotify. What we do instead is use the /application/{Id}/message REST path and recursively retrieve all the messages by using the Gotify pagination. After that, we sort all the messages and only then apply the user-requested date-range filter. I am unaware of any correlation between the since parameter and the actual date when the notification was sent, is there a correlation?
As you can imagine, if the Gotify server has been running for a while, retrieving all the messages or going through all the messages just to find a date-range is a miserable experience for the user, let alone the fact that loading the messages just means more a/deallocations producing memory spikes unnecessarily (this is something that we can optimize on our end, but not the time it takes to retrieve them all).
Would it be possible for you to add a hook for the API that would allow the retrieval of messages from a given application by applying a date-time filter? Right now there is:
/application/{Id}/message
so maybe something like:
/application/{Id}/message/{date}
or part of the rest of the other parameters
/application/{Id}/message?date=...
By implementing this, time to the amount of linear time complexity O(a * m) where a would be the number of applications and m would be the number of messages could just be reduced to O(a). In case the application ID is known, which in many cases it is because the option in our software is usually provided from the UI to select an application, then the whole O(a *m) is reduced to just a single operation O(1) which is an amazing performance boost at no cost.
I have not looked into Gotify myself, so I do not know the internals and I haven't dabbled in Go yet but the actual date when a notification arrives is already recorded by Gotify internally as part of the message structure such that it should not be too costly. We also filter by other criteria when searching, but that criteria is not to be found in your Gotify message structure so that would be more difficult.
Feature request #376 seems somewhat related given that a notification typically has a very short lifespan because it is supposed to notify the user what happened "now" contrasted to say a database that can hold long-term data. However, at the same time, browsing through age-old notifications like "outdoor lights went on" that took place a month ago seems irrelevant. Pagination is great for an UI when a user can click inputs and browse pages of data arranged such that not too many appear at the same time, but when you are accessing Gotify programmatically like from Winify, pagination can take a huge time and makes a bunch of useless requests.
Could you please implement this REST API path?
Thank you!
- Lenguaje dominante
- Go
- Estrellas
- 16k
- Forks
- 891
- Merge medio
- 2 d 11 h
- PR fusionados (30 d)
- 6
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de gotify/server
-
a:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
gotify/server#1068 · 1 reacción ·
Los mantenedores suelen responder en 2 días
-
Session elevation duration is unbounded, and large values silently overflow to a past timestampPosiblemente ocupada @piyush295 la tomó hace 12 días. Abiertoa:bug
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
gotify/server#1051 · 2 comentarios ·
Los mantenedores suelen responder en 2 días
-
a:bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
gotify/server#1047 · 6 comentarios ·
Los mantenedores suelen responder en 2 días
-
a:feature
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 2 días
-
OIDC: Disallow changing admin permissions for oidc users when OIDC group mapping is configuredAbiertoa:feature
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 2 días
Todos los issues de gotify/server
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
bug good first issue load-balancing
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
ktrubilo9/edge-proxy#53 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
[receiver/dockerstats] ContainerEnvToMap truncates environment variable values containing "="Abiertobug needs triage receiver/dockerstats
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
open-telemetry/opentelemetry-collector-contrib#51948 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
LanternOps/breeze#8353 ·
Los mantenedores suelen responder en 1 día