Devlog 3: Three Hours of My Life I’m Never Getting Back (And Slack’s Media Renderer Can Thank Me For It)

The false confidence

I thought the bot was done. I really did. The commands worked, the database was syncing, the cron jobs were firing. It was a fully functional space bot. I sat down to do what I thought would be a 15-min final polish before shipping. Three hours later, I was found questioning my reality and whether I should just delete the folder and take up farming. What started as a quick polish turned into a full-blown war against dead community APIs, Slack’s deeply picky Block Kit renderer and the absolute garbage fire that is Node.js DNS resolution on free hosting platforms.

The dead API saga

First, /skl-mars completely died. Not a graceful failure. Not a friendly JSON error. It just silently redirected to a GitHub Pages 404 HTML page. Axios, bless its optimistic little heart, tried to parse that HTML as JSON, choked and took the whole bot down with it. I made the executive decision to ditch that entirely. The rover is probably tired of taking photos anyway. I swapped it out for NASA’s EPIC API, which takes photos of Earth from the DSCOVR satellite. But EPIC had its own trap. If you just ask for the “most recent” photos, it returns a tiny array of about 13 photos from the last active day. The bot kept spamming the exact same image of Earth. I had to rewrite the endpoint to fetch the archive of all available dates, shuffle the entire history of the satellite and pull a random day from the past just to get some variety. Then, the Open Notify API (used for ISS location and crew data) went offline too. Same GitHub 404 redirect. I had to write nested try/catch fallbacks with 5-second timeouts to route requests to wheretheiss.at just to keep the telemetry commands alive. It was a war of attrition against community-run infrastructure.

Slack Block Kit & the APOD nightmare

Getting the APOD (/skl-apod) to actually render in the chat was an absolute nightmare. Originally, the bot just dropped a raw URL into the chat. Slack looked at it and said “Cool link, not displaying it” so I rebuilt the command using Slack’s Block Kit image block. That fixed images. But.. a video? Because of course, if you pass an .mp4 URL into an image block, Slack silently drops the message entirely. I had to write logic to check the media_type: if it was a YouTube link, I parsed the URL and rendered it using Slack’s native video block. If it was a raw .mp4, I had to stream the video file directly into Slack using filesUploadV2 so it would embed and play right in the chat. And to prevent the bot from OOM-crashing the server on large videos, I had to use responseType: "stream" so it chunked the download instead of loading a 50MB video into RAM all at once.

The Nest hosting quirk

Right when I thought I was victorious, APOD and Earth started failing with getaddrinfo ENOTFOUND api.nasa.gov. After staring at my screen wondering if I had forgotten how URLs work, I learned that Node.js 17+ defaults to IPv6 for DNS resolution and the hosting platform (Nest) doesn’t fully support IPv6 routing. The server literally couldn’t find NASA. Adding dns.setDefaultResultOrder('ipv4first') to the top of the service file fixed it instantly. Extremely normal behavior, I love computers.

The actual architecture shift

Amidst all the API firefighting, I also ripped out the hardcoded .env channel routing. Making someone edit a .env file just to move a bot to a new channel is a crime. I moved the scheduled announcements to a SQLite-backed system with /skl-setup and /skl-unset commands so the bot could support multiple servers dynamically without touching environment variables. What started as a simple script turned into a much more reliable bot with backup APIs, saved data, scheduled posts and the ability to handle images and videos directly in Slack. It was hella exhausting, my brain is completely fried but atleast it’s done.