Webhook Issues Following Force Shutdown

[cameron-b63]

Webhook Issues Following Force Shutdown

After a forced shutdown, the Discord webhook will not post messages without some finagling and plenty of restarting. Macro logs show successful event detection and even 200s on POST requests, but still no messages in the Discord channel. I discovered this following a power outage.

Reproduction

I can consistently reproduce the issue by:

1. Opening the Roblox Player in my Sols RNG private server;
2. Starting the biome macro;
3. Waiting for a successful webhook message to come through;
4. Forcefully shutting down the PC.

After restart, the macro appears to be working but there are no messages coming through the discord; additionally, the webhook does not send a "macro stopped" message on force shutdown.

Current State of Recovery

Currently, I can successfully get the macro working again by:

1. Opening the Roblox Player in my Sols RNG private server;
2. Starting the biome macro;
3. Waiting for a biome change which should trigger the webhook;
4. Closing the Roblox Player;
5. Stopping the Biome Macro;
6. Waiting for at least 5 minutes;
7. Opening the Biome Macro;
8. Waiting for at least 1 minute;
9. Opening the Roblox Player.

Sometimes, I must repeat the process more than once.

Suggested Fix

I took a look around, and it seems to me that the correct approach is to use a signal handler so that shutdown still attempts to gracefully close the webhook. My theory is that the desync stems from Discord, not necessarily from the biome macro, so we at least need to try to get that web request out during WM_QUERYENDSESSION or WM_ENDSESSION (the latter taking place during a less graceful shutdown iirc).

I will open a PR if I find time in the coming days.

Potential Issues

Signal handlers are infamous for cross-platform compatibility issues. This doesn't appear to be a problem right now, but you may experience different incarnations of this issue if you decide to support more devices in the future.

Device Info

Edition Windows 11 Education
Version 25H2
Installed on ‎5/‎21/‎2025
OS build 26200.8457
Experience Windows Feature Experience Pack 1000.26100.304.0

Processor AMD Ryzen 7 3700X 8-Core Processor (3.59 GHz)
Installed RAM 32.0 GB (31.9 GB usable)
Device ID 98BB3A6A-1EFE-4987-B96C-DF84050373C9
Product ID 00328-20090-00000-AA974
System type 64-bit operating system, x64-based processor
Pen and touch No pen or touch input is available for this display

[maxstellar]

This is very thorough! Thanks for the write-up. I'll look into the issue and patch it if I can find time. Feel free to open a PR. In the meantime, I will make sure my source code is up to date.

[cameron-b63]

Looks like I'm gonna have time tonight, but I'll wait for a commit or confirmation that source code is synced before I fork.

[cameron-b63]

This actually ties back to a much bigger issue with log file detection. Going to need to look into this a little bit, but it looks like there are instances (even without the crash) that cause the log file targeted by biomemacro to contain the following content:

[FLog::Output] All use of Roblox services must comply with Roblox's Terms of Use, Privacy Policy, Community Standards, and applicable laws. Processing of User personal information is limited to the purposes expressly permitted therein.
2026-05-30T01:37:36.184Z,0.184905,1558,6,Warning [FLog::RobloxStarter] Starting module: Logging
2026-05-30T01:37:36.184Z,0.184905,1558,6,Warning [FLog::RobloxStarter] Starting module: Network
2026-05-30T01:37:36.185Z,0.185905,1558,6,Warning [FLog::RobloxStarterNetworkStarterModule] userAgent: Roblox/WinInetRobloxApp/0.723.0.7230785 (GlobalDist; RobloxDirectDownload)
2026-05-30T01:37:36.185Z,0.185905,1558,6,Warning [FLog::RobloxStarter] Roblox stage ReadyForFlagFetch completed
2026-05-30T01:37:36.187Z,0.187905,1558,6 [FLog::Output] RobloxChannel has been set to production
2026-05-30T01:37:36.187Z,0.187905,1558,6,Warning [FLog::Output] NoReload Detector: warm start adjustment: 191
2026-05-30T01:37:36.188Z,0.188905,1558,6,Warning [FLog::Output] NoReload Detector: App NoReload!
2026-05-30T01:37:36.218Z,0.218621,1558,6,Warning [FLog::RobloxStarter] RobloxStarter destroyed

And then apparently there's a fallback to the next most recent log file. There's something fishy going on with Roblox caching, and I can see that there's a lot more to log detection than I thought. It may be wiser to just create a button which clears the log files or renames them so that roblox won't recognize them (or move them into a new folder, etc. etc.); worth exploring.

This may be its own issue. Have to see. It looks orthogonal.

[cameron-b63]

Total sum of needed changes:

1. Create a signal handler that eats the shutdown interrupt and calls the stop() function first (could even add an argument to stop for a more robust webhook message on crash)

Potentially, could add a feasibility check for the timestamp of the entries in the latest log file finder to make sure it's not from a previous run (I experience this issue pretty frequently, where biome macro ends up getting tied to a previous instance of the roblox player instead of my current server).

Both of these combined should prevent any of the issues described.

[cameron-b63]

#4