deploy_feedback

I posted about this earlier this month in the deploy channel but figured I'd create an issue for it since others have run into the same issue when trying to deploy from a github action instead of using deno deploy's build settings. Found out that the deno deploy cli command is respecting gitignore. If I have my public/build directory in there, it doesn't get deployed when running the deno deploy cli command from my github action. If I instead have my build command configured in deno deploy so it runs on their server instead of the github action, the build artifacts in public/build are not ignored. To be able to deploy my build artifacts from my github action without removing it from my gitignore, I had to add a step that removes it from gitignore before running the deploy command. Why does the deno deploy cli command respect the .gitignore and is there a different way to work around it other than unignoring it? The help flag doesn't appear to show any other arg options to ensure these build artifacts are included when the application is deployed. Here is an example url for a deployment done without that new unignore step. The build file is missing. https://udibo-8abdsr1vc5td.udibo.deno.net/build/main.css Then once I add that step, it successfully uploads that file. Here is an example of the file I was expecting to get uploaded. https://udibo-c1159q6nkm38.udibo.deno.net/build/main.css Just including those preview urls in case it can help with identifying why this is happening. I think it's not uncommon for people to gitignore build artifacts. Here is another example showing that before switching to a github action, when the application in deploy is configured to run the deno task build:prod command, it doesn't ignore the artifact. so it seems gitignore only applies to the cli command and not to the app configuration build command. https://udibo-k3ek9cwh5p11.udibo.deno.net/build/main.css

Question Is it expected that process-level Memory Usage stays flat (~170 MiB) during long idle periods (0 HTTP requests for several hours), while V8 allocated heap size drops to near zero in the same time range? Metrics screenshot (Last 24h) !Deno Deploy metrics - Memory Usage flat at ~170 MiB while V8 heap drops to ~0 during idle period Environment App: Deno Deploy, dynamic runtime : Observations (Last 24h Metrics dashboard) During the active half of the window: HTTP req/min has spikes CPU Time has spikes V8 allocated heap fluctuates (up to ~500 MiB) Memory Usage fluctuates (~120–200 MiB) During the idle half (confirmed by Logs: no application logs for hours): HTTP req/min = 0 CPU Time ≈ 0 V8 allocated heap ≈ 0 Memory Usage stays flat at ~170 MiB for the entire idle period What we checked Logs show no requests during the idle period (no application log output) Runtime docs say apps stop after 5s–10min without traffic Changelog mentions both V8 heap metrics and process-level Memory Usage as separate metrics Questions 1. When an isolate is fully stopped due to idle, should Memory Usage drop to 0 / stop reporting, similar to V8 heap? 2. If Memory Usage stays ~170 MiB while V8 heap is ~0 and requests are 0, does that mean: a warm process/isolate shell is still kept alive (native RSS baseline)? or the Memory Usage chart holds the last value / uses different aggregation during idle? 3. Is idle-time Memory Usage included in memory-time (GB·h)** billing, or only periods when the isolate is actively running? Why it matters Trying to understand whether ~170 MiB flat line during zero-traffic hours indicates real ongoing memory consumption vs. a metrics display artifact. V8 heap dropping to zero suggests application heap is released, but the flat Memory Usage line is confusing. Thanks!

Disclosure: this report was written by Claude (an AI coding assistant) while diagnosing CI failures on behalf of Kyle June, who reviewed and submitted it. Summary When the server closes the subscription without ever delivering the label, the CLI exits with a cryptic runtime crash instead of an error message: Cause In (0.0.9904), the missing-hashes promise is only resolved from when the label arrives; reports properly, but just unsubscribes without resolving or rejecting**: ``@deno/deploy` 0.0.9904, Deno 2.9.x, non-interactive CI (GitHub Actions).