Hello. Our GitHub repo uses webhooks to call a Glitch project to manage our repo tickets.
I’m seeing on average that out of 50 calls about 10 fail with a response 504
do you have logs from the project during these failed calls? I haven’t seen reports about glitch middleware using the 504 status code. or do you know what the http response body was in these cases? did it look like something coming from glitch, rather than from your project?
From the GitHub side I just see the 504, without headers or body details 
From the Glitch project side, once I start the project and check the logs, I cant find any log messages related to the 504, so it appears to me that the GitHub call to Glitch never got as far as successfully starting the project, which I think implies that it was the Glitch server gateway that timed out with a 504, and not the started project?
If I force GitHub to redeliver, then I see the log activity from the project related to the GitHub WebHook call and response.
Unfortunately (from a debugging point of view), because redeliver from GitHub always succeeds, I’ve not been able to conclusively confirm that there has not been any log activity on the Glitch project side when a 504 occurs.
But if there is a timeout and the project is never started then I guess that makes sense?
maybe the project takes to long to initialize from being asleep? to my understanding, these webhook kind of requests aren’t allowed to see that “waking up” interstitial page that you get from opening a glitch project in the browser. could it be trying to install some big dependencies and glitch’s reverse proxy stuff gives up?
That seems like a possibility.
Logs show that starting the project from the Glitch dashboard the project install time takes about 12380ms and once running responds within 0.2 to 0.8 seconds.
We were forced to upgrade node.js in the package.json from 8.9 to 10.24.1 last week due to Glitch’s new minimum node.js specs.
The GitHub WebHook log shows that the calls that succeed complete within 0.2 seconds through to 8 to the longerst at 9.86 seconds, while those that fail all are marked as complete at 10 seconds.
I’m guessing the short times are when the project gets calls while is still running, until the project is shut down by Glitch to release resources (part of the penalty of using the free service), and the 8 second start up is one of the better start up times, but 10 out of 50 calls the startup takes longer than 10 seconds so either GitHub gives up waiting or the Glitch gateway send back a 504 for exceeding 10 seconds to respond?
what’s involved in startup? if you’re using nodejs 10 or 12, you have the option of using pnpm to install dependencies from glitch’s local cache, which could save time.
I just realised I did not provide any context for the link to the issue-bot.
So This Glitch project was set up by a member of our team a very long time ago and had been running flawlessly for years and years.
However that team member has left and I’m putz-zing my way about getting the bot working again after it failed when Glitch mandated the node.js version upgrade to get it running again.
Anyway, the short of it all is that I have no idea how to modify the project to use Glitch’s local cache.
Presumably it’s not as simple as just replacing the engine entry for npm with pnpm in the package.json file?
Suggestions welcome. Thanks.
you’d run enable-pnpm in the project terminal. that’s a glitch-specific thing. you can run enable-npm if pnpm doesn’t work out
do you have any sense if it’s actually the dependency installation that takes a while? might be able to check the timestamps in the project logs to see what’s taking up those ~12 seconds
ok, new data. I enabled pnpm and waited an hour to let Glitch shutdown the active project.
Then I created a new issue on GitHub and looked at the WebHook logs, and compared them with the logs from the project.
by matching the ids, the following:
WebHook
2024-01-15 20:42:35 9fafd720-b379-11ee-84a8-9c842f5bfc94 issues.opened response 504
Project
Total install time: 8623ms
2024-01-15 20:42:39.368 INFO probot: The app was loaded!
[before-after-hook]: "Hook()" repurposing warning, use "Hook.Collection()". Read more: https://git.io/upgrade-before-after-hook-to-1.4
2024-01-15 20:42:39.739 INFO probot: Listening on http://localhost:3000
DEPRECATED (@octokit/rest): `apps.getInstallations()` is deprecated, use `apps.listInstallations()`
DEPRECATED (@octokit/rest): response.meta – use response.headers instead (#896)
DEPRECATED (@octokit/rest): `apps.getInstallationRepositories()` is deprecated, use `apps.listRepos()`
2024-01-15 20:42:41.341 INFO http: POST / 200 - 79.96 ms (id=9fafd720-b379-11ee-84a8-9c842f5bfc94)
2024-01-15 20:42:41.341 INFO probot: New issue created
DEPRECATED (@octokit/rest): `issues.getForRepo()` is deprecated, use `issues.listForRepo()`
DEPRECATED (@octokit/rest): `repos.getContent()` is deprecated, use `repos.getContents()`
20:43:00.117 INFO http: POST / 200 - 0.77 ms (id=b4690420-b379-11ee-847e-2dbdf8949277)
so the WebHook log for the 504 is at 20:42:35, but probot was active at 20:42:39 and processed the new issue by 20:42:41.
And if we subtract the 8.6 seconds initialisation, the project was initiated at 20:42:30 ish.
all those deprecated messages are related to probot, but I assume they are a warning, the function is still performed but the replacement commands are encouraged.
I cant reconcile the WebHook timestamp with probot activity.
is 20:42:35 the time the WebHook initiated the call, and the completed in 10 seconds means the WebHook waited until 20:42:45 to log the 504?
If so how does that fit with the project beginning at 20:42:30 and finishing the task at 20:42:41?
I’m so confused.
could be that an HTTP gateway somewhere gave up and sent a 504, but stuff downstream had no way to cancel the request and so continued to deliver the request to your project after initialization
Yeah, that may well be the case.
If so, then I’m not sure what else I can do.
For now I’m just working on trying to reduce the initialization time, and get rid of all the deprecated warnings. May also update node and npm to more current versions, albeit, typically, I’ve found that new releases are usually more bloated with features and take up more resources, rather than become quicker and lighter.
oh, well, thanks for you help so far, appreciated it.