Behind the scenes, I’ve been digging deep into the cryptography involved with Push Notifications. It’s got many parts to implementing the logic to create a symmetric key, encrypt a payload in addition to other information, Encrypting the symmetric key with the end-users public key, and digitally signing a header with my VAPID private key to form a JWT token. Lot’s of stuff…

In the meantime, in the name of pushing out content, here is my first encounter with the Hostinger tech support. It’s nothing impressive as the problem resolved itself without anyones interaction.

Build Server

GitHub Actions are amazing. They are a great way to setup a build server for someone just starting out on a project. My main concern is that I don’t want to run into a situation where my minutes expire, or that I have an astronomical bill to pay. Restricting people by minutes adds an uncertainty of cost and pressure to rush. It reminds me of the old days of long distance calling and being charged by the minute for America Online (AOL) dial-up service in which the rates changed based on the time you called.

To combat the possibility of hanging, I added timeouts to my build scripts of 1 minute. If the build starts to take longer, I can evaluate if something with the build itself needs to be addressed, or add additional time before it times out. The goal is to prevent wasting minutes or hours with a hung process.

Here is an example of how I added the timeout in YAML

name: Development
jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    timeout-minutes: 1 # Don't let FTP hang

Normally FTP just takes a few seconds. If I didn’t have the correct login credentials, it would hang. GitHub wouldn’t (or couldn’t) detect that it was hanging and would have let an individual job run for six hours (or the entire workflow for 35 days) without the timeout – thus burning up my 2,000 minutes fairly quickly.

Tonight the FTP step started to hang again. I’m using sebastianpopp/ftp-action to transfer files. Previously it appeared to hang due to a .env file affecting it – but I can’t be certain. Once I removed the file, the upload worked. I would need to test and confirm if that was the issue or not. I’ve also had trouble getting secure FTP working with it as well, but I think that’s more of an issue with my hosts FTP server.

This time was something different. At 1:30 AM, a workflow ran fine. At 1:39 AM, the next workflow failed. Running the workflow again with debug info didn’t reveal anything new other than stack traces when the job exceeded the time limit. The FTP plugin doesn’t mention any problems.

I opened FTP Rush and found that I was able to login, but that a connection couldn’t be established to send the directory data.

[2][FTP]Status: Start Login dev-api.periplux.io ...
[2][FTP]Status: Connecting to 194.164.64.119:21
[2][FTP]Status: Text encoding: System.Text.UTF8Encoding
[2][FTP]Status: Login dev-api.periplux.io Successfully
[2][FTP]Status: Start List directory / ...
[2][FTP]Error: The specified data channel type is not implemented.

Just for added measure, I tried the same thing with four different FTP accounts and got the same error after logging in.

Overview of FTP Directory Listings

FTP runs on two ports. The main one (port 21) is a port used to talk to the server. I ask the server for a LIST. The server says “Yea, I understand you want a list”. We then decide on a separate channel/port based on the mode. In active mode, the server opens a channel and waits for me to connect. In passive mode, my software opens a channel and waits for the server to connect. I’m using passive mode by default. Once the connection is made, the server creates a list as ASCII text and sends it to me. Once completed, the connection is closed. The server then sends me code indicating it was successful (or failed).

Self Help

Something was preventing the server from connecting to me. It wasn’t just me – it was GitHub build servers that had the same problem as well. I started hunting online for answers and then went to Hostinger’s to check if their status was up. No issues reported. I looked at the support area and couldn’t find any information regarding the search phrase

FTP says “The specified data channel type is not implemented.”

Choosing a category to contact support was very confusing as none of the options seemed to fit the category of my issue. As I selected a category, they got more specific in what your issue was. FTP server errors didn’t seem to fit into anything.

I settled on Website issues and said the website is down or displaying an error. Mind you, the website was operating just fine.

Clicking the Chat Now area was unresponsive. I tried it a few times and eventually someone popped up.

How can I assist you?

FTP Stopped working. After I log in, I try to list a directory and it says “The specified data channel type is not implemented.” I’ve tried this with four separate accounts and get the same error.

I don’t know how to switch active/passive mode. This worked previously over the past few days and suddenly stopped working within the past 30 minutes.

(Mind you, I just hadn’t bothered to switch it. Given that the configuration worked 30 minutes ago, I knew none of these were the issue. I was trying to drill in the fact that this suddenly started, and I was able to connect without a problem previously)

For FTP Rush, it’s under the Option -> Option menu and in the FTP Protocol section under Data Transfer Mode as Auto, PASV, or PORT.

During all of this, I was still trying every now and then to disconnect and reconnect, hoping insanity would solve the problem.

To my surprise, the server started responding just fine listing the contents of my directory.

Just to confirm, I kicked off the original workflow that was failing around 2:00 AM and it worked just fine.

No worries. It looks like the problem resolved itself. I guess your servers had a hiccup or something.

Great to hear that everything is working again! If you encounter any more issues or have further questions, feel free to reach out. Happy browsing!

So just evaluating what happened

• GitHub actions started hanging during FTP transfer
• sebastianpopp/ftp-action does not provide any feedback and hangs
• YAML timeout prevents wasting minutes
• FTP credentials were correct
• FTP authentication was not a problem
• FTP server could not establish data channel to send directory listings
• FTP server was online, but unusable for about 30 minutes
• It’s a bit confusing in how to contact Hostinger’s support if your request doesn’t fit in a predefined category
• Hostinger responded to a support request at ~1:30 AM Eastern
• The responses were fairly generic (AI Generated?)
• The problem resolved itself.

Results

• YAML timeout was a good idea. Should be done on all YAML scripts.
• Need to evaluate other potential FTP actions to fail fast
  • This issue should have been caught immediately by the ftp-action and fail the job
  • The job has hung in the past for other reasons
• Can’t depend on First level support as they appear to be oblivious to the meaning behind technical details and works from a script.