Cancel POST Request node while in progress

The POST Request node in KNIME works great typically, but if anything goes wrong with the endpoint (e.g. the API goes down, bad URL, a bad API key was passed in via the header, a local web service was stopped, etc.) the node will likely show a spinning progress bar (no progress being made) and will continue to spin even after the user clicks “Cancel all running nodes” or attempts to cancel the POST Request node specifically.

I’ve run into this multiple times. The only way to actually cancel the process is to shut down KNIME. If you close and reopen the workflow, at least you are able to edit the node’s config and try again. However, I confirmed via local testing of an API running on localhost that the POST Request node will continue to send requests regardless of cancellation or even closing the workflow unless the KNIME client is shut down completely.

This has been an issue I’ve run into periodically for over a year, so it has spanned multiple versions and appears to still be an issue in 4.1.2.

4 Likes

For testing this issue on your end, I recommend:

  • Create and run a small python/flask microservice on localhost that prints all requests to console
  • Send 50,000 POST requests to it (or enough requests that you will have time to perform other actions) via the POST Request node
  • Stop the microservice after the POST Request node has begun running
  • Confirm that you are unable to cancel the POST Request node
  • Confirm that log messages are still showing up in the microservice console
  • Shut down the KNIME client
  • Confirm that log messages are still showing up in the microservice console

Clarification: may need to send bad requests (e.g. invalid JSON) to the API if it’s locally hosted. For external API’s, an invalid API key should do the trick.

Hi @sjporter -

Thanks for the detailed bug report! This issue has come up in another context recently with the Java Snippet node too (Endlessly running JavaSnippets can't be canceled), and we recently created a ticket around that (Internal: AP-14266). I will add a link to your comments to that ticket as a +1.

Sorry for the annoyance with having to manually shutdown. I hope we’ll be able to knock this one out soon.

4 Likes

Saw the same issue again today on a JSON to Table node.

1 Like

I also observe this behavior. The console shows timeout exceptions of requests long after the corresponding workflow has been closed :face_with_hand_over_mouth:

Also it seems like these kind of “orphaned” requests break the progress reporting of other Request nodes. The progress bar just shows an “undetermined” progress.