# GitHub webhook delivery fails on update

An update committed to your GitHub scenario repository is not showing up in Katacoda. Viewing the https://editor.katacoda.com/scenarios/updated webhook in your Katacoda Scenarios settings on GitHub you see errors in Recent Deliveries that say Invalid HTTP Response: 423.

GitHub webhook error 423

A 423 response indicates that your Katacoda scenarios are currently locked. The most common reason for them to be locked is because they are already regenerating scenarios from an earlier commit. If this is your most recent delivery attempt then:

  1. Wait for your current build to complete on Katacoda.
  2. Click the redelivery button next to the failed delivery attempt on GitHub, or push a new commit to your repository.

If builds continue to fail, there may have been a problem completing the original failed build and it cannot clear the lock. Katacoda locks have a 60-minute timeout. Wait for 60 minutes and try again.

The larger and more complex your scenario repository is, the longer the rebuild process can take. If you are committing updates frequently to a large repository you are more likely to see this problem.

# Connection to host01 closed

The Terminal window is closing prematurely or unexpectedly. It returns the error:

Connection to host01 closed.

The environment has expired.

Please refresh to get a new environment.

# Try again if the problem is infrequent

A lost connection might indicate a timeout or a network problem that broke a web socket connection to the terminal. You will need to start this session over. You can do this be reloading your web page. Your progress will be lost.

# Consistent failures indicate scenario problems

If the problem persists or happens consistently in the same spot, the scenario may be executing something that is altering the terminal behavior.

One observed cause of this:

# "set -e"

Did you source a script with "set -e"? Normally this is not executed directly in an interactive shell. It is commonly used in scripts so they stop executing when a line in the script fails to execute. In one case a shell script with "set -e" was being "sourced" from the command line.

source my_broken_script.sh

This caused the terminal to terminate the next time a command failed to execute. It didn't fail immediately but failed within a few steps after the change had been made.