Skip to content

[IDEA] Be able to cancel a search that I started #409

Description

@anibal2j

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!

Activity

  1. jonbartels commented on Aug 10, 2026

    @jonbartels
    Contributor

    I know this was discussed at some time on the old forums or the old Mirth Slack.

    Some notes:

    • the searches are long running HTTP requests waiting for data
    • We could kill this client-side only - However this would still leave a potentially long running or slow query going server-side
    • We could add a kill option that operates server-side - This would require some sort of coordination in sending the search so it can be killed and server side orchestration to kill it. I don't remember how to do this in Java, JDBC, mybatis etc but I'm sure there are modern tools to do it
    • The slow searches can come from three places:
    • a slow DB query, how can this be killed with a kill signal?
    • slow marshalling of the XML returned to the client
    • slow unmarshalling or rendering of the XML in the client
  2. david-labs-ca commented on Aug 13, 2026

    @david-labs-ca

    I am in favor of stopping such requests at client even before sending to server. Chris and I are working on a PR on his web-client to implement the same. [PR#33] (gibson9583/oie-web-client@97edb89)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions