#Technical sanity check: is ~2:16 enough for a manual redeploy/restart of a .NET Discord bot?

1 messages · Page 1 of 1 (latest)

strange wind
#

Hi everyone! I’m a regular participant (not a programmer) looking for a neutral timing opinion from people who deploy/maintain .NET services or Discord bots.

During a wager, a Discord bot (main prefix !) posted 97 from a public d100 command run by the bot owner (also the bot’s author/maintainer). Using Discord snowflakes/message IDs, the window from my “start” signal to the d100 command + the bot response was ~136.6 seconds (~2:16).

I summarized the owner’s message for brevity; I can paste the original quote if needed. The owner said that changing behavior within that window would require a manual sequence roughly like:

  • locate/edit logic
  • dotnet publish -c Release -r linux-x64 --self-contained false
  • stop the bot (!quit)
  • replace binaries via SFTP
  • SSH as root and restart (they mentioned screen/chmod), with temporary downtime

Others estimated this full cycle is typically 5+ minutes due to code search + build/publish + upload + restart/startup overhead. The codebase size was discussed as ~50k+ LOC.

Extra context (not proof about the exact moment): a few hours later I saw a screenshot indicating the owner uses configured SFTP/SSH tools (FileZilla/PuTTY) with saved sessions/connection details (not sharing it publicly). This doesn’t prove what was open at the time, but makes a warm-start workflow plausible.

Question: in your experience, is ~2–3 minutes more likely enough or more likely not enough for that kind of change + deploy/restart (warm vs cold start)? If feasible, what assumptions would make it feasible?

brittle stirrup
#

the thing is
It really depends

#

depends on the actual code
the way it does things
maybe it often blocks the gateway thread
maybe it's running on a slow host
maybe it has too little bandwidth
maybe it's running 10000 shards for millions of servers / tens of millions of users

#

maybe it caches every single user on startup
etc

#

there's no cold/warm start logic built into dnet
if you restart the process, the state cache is lost

#

unless you mean recompiling as a part of deployment

#

I would recommend adding proper telemetry & metrics

strange wind