[IDEA] Be able to cancel a search that I started
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
Línea de trabajo
The request is a cancel control for an in-flight GUI search that currently blocks further searches until the query finishes, including aborting the database pipeline. Start from how search is launched in the client UI and how that call reaches the engine/DB, then identify an existing cancel or interrupt path if any. Done means a user can stop a long search, the GUI becomes usable again, and the backend work is actually terminated rather than only hidden.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Is your feature request related to a problem? Please describe.
I use search daily. I can be searching for anything, an accession number (which I always put in metadata) or a given string (yes, it's bad, but I usually use some other filters to narrow the depth of the search). Some times a search is taking forever and then I notice that it won't return anything. The GUI is pretty much toast now and any new searches will not work until the first one finishes.
Describe your use case
I need this feature so I can accomplish doing a search that I know will work, compared to the one that I started and it's killing the DB for no reason - since no results will come out of it (potentially after scanning the whole table)
Describe the solution you'd like
There should be a cancel search button that just kills the whole pipeline going to the DB.
Describe alternatives you've considered
My workaround is to kill the GUI completely and re-launch a new one. ugh!
- Lenguaje dominante
- Java
- Estrellas
- 227
- Forks
- 81
- Merge medio
- 3 d 6 h
- PR fusionados (30 d)
- 15
Preparar el entorno
- Incluye un Dockerfile o un 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 OpenIntegrationEngine/engine
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#485 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
OpenIntegrationEngine/engine#478 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#355 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#347 ·
Los mantenedores suelen responder en 1 día
-
Fix call-home in test runAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#313 ·
Los mantenedores suelen responder en 1 día
Todos los issues de OpenIntegrationEngine/engine
Issues similares
-
NullPointerException when a `DeserializationProblemHandler` returns `null` for `byte[]` (single value unwrapped) and `char[]` elementsPosiblemente ocupada @Marti2203 la tomó hoy. Abierto
Dificultad 2/5 Medio día Aptitud para principiantes 88/100
FasterXML/jackson-databind#6300 ·
Los mantenedores suelen responder en 1 día
-
content good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
cpinitiative/usaco-guide#6699 ·
Los mantenedores suelen responder en 1 día
-
BC remittance upload: a claim MSP refused (S03) is saved with a blank status instead of refused (F)Abiertotype: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
carlos-emr/carlos#4933 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/rocketmq-dashboard#6925 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Vakore/ZappierGames#147 ·