chore: daemon logs

[tlgimenes]

Summary by CodeRabbit

• Chores
  • Added comprehensive runtime logging across publish/build workflows (start, duration, completion, payloads) with no functional changes
  • Added periodic progress warnings and detailed status logs for metadata synchronization, including explicit 404 handling and retry behavior
  • Added lifecycle and startup error logging for worker initialization and request-handling paths
  • Added verbose port connectivity diagnostics and timing for connection waits and failures
  • Updated runtime tool version fields in manifest files (version string changes only)

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[github-actions]

Tagging Options

Should a new tag be published when this PR is merged?

• 👍 for Patch 1.132.3 update
• 🎉 for Minor 1.133.0 update
• 🚀 for Major 2.0.0 update

[coderabbitai]

Walkthrough

Adds pervasive runtime logging across publish/build, meta watching, worker lifecycle, and port utilities; introduces worker startup error handling that rejects the startup promise on failure. No exported API or signature changes.

Changes

Cohort / File(s)	Summary
Publishing & Build Logging daemon/git.ts	Adds console logging throughout the publish/build flow: publish request receipt (author/message payload), per-oid build lifecycle (start, duration, removal), buildMap add/remove, GitHub App token netrc setup, git fetch/submodule/reset steps, commit creation payloads, and build pipeline initiation. No functional changes.
Metadata Monitoring Enhancement daemon/meta.ts	When awaiting promise-like meta, starts a 10s periodic warning timer and logs resolution; watchMeta adds attempt counting and detailed logs for tick cycles, etag handling, fetch responses (including explicit 404 handling that clears meta and emits a final payload), and error statuses while preserving prior retry semantics for 408.
Worker Initialization & Error Handling daemon/worker.ts	Adds typed middleware signatures and runtime lifecycle logs (start, isolate, readiness). Wraps initializeWorker in try/catch, logs errors and rejects the worker-start promise on failure to avoid hangs; middleware responds 424 if worker not ready; shutdown awaits options resolution and logs errors.
Port Monitoring Logging daemon/workers/utils.ts	isListening now logs caught errors; waitForPort gains verbose start/success/timeout/abort logs with elapsed times; timeout literal reformatted to 10_000. No signature changes.
Deno manifest updates deno.json, dev/deno.json, scripts/deno.json	Pin/version fields changed from 1.132.2 to 1.127.6-beta.1 in three manifest files. No other structural or behavior changes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Inspect daemon/worker.ts initializeWorker try/catch and wp.reject to ensure startup promise is always resolved/rejected and middleware 424 path behaves as intended.
• Verify daemon/meta.ts periodic warning timer is always cleared in resolve/error/finally paths and that 404 handling emits the expected final meta payload.
• Review daemon/git.ts for potential sensitive data being logged (commit payloads, tokens) and for excessive log volume in tight loops.
• Confirm daemon/workers/utils.ts waitForPort logging does not alter timeout/abort semantics.

Possibly related PRs

• Deconfig provider + automatic rebase #968 — Modifies daemon/git.ts (adds assertRebased and automatic rebase logic) and touches the same publish/build code paths as this logging-focused change.

Poem

🐰 I hopped through logs at break of dawn,

Commit and build and ticked-off cron.
If a worker stumbles, I shout "Not fine!"
I reject the hang and clear the line.
Carrots of insight, freshly logged and mine.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'chore: daemon logs' accurately reflects the main change—adding extensive logging throughout daemon modules without altering core logic.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch daemon-logs

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f3bc48b and 4d96ae7.

📒 Files selected for processing (3)

• deno.json (1 hunks)
• dev/deno.json (1 hunks)
• scripts/deno.json (1 hunks)

✅ Files skipped from review due to trivial changes (3)

• dev/deno.json
• deno.json
• scripts/deno.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: publish

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

daemon/workers/utils.ts (1)

7-9: Consider removing or reducing log verbosity in the polling loop.

This function is called repeatedly inside waitForPort's polling loop (line 25). Logging every failed connection attempt will flood the logs when waiting for a port to become available, especially with the 1-second polling interval.

Consider one of these approaches:

• Remove this log entirely since waitForPort already logs the overall wait status
• Move this logging to the caller level where it can be controlled contextually

Apply this diff to remove the noisy log:

-  } catch (err) {
-    console.log(`[isListening] Error connecting to port ${port}:`, err);
+  } catch {
     return false;
   }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c697152 and 9554ca1.

📒 Files selected for processing (4)

• daemon/git.ts (1 hunks)
• daemon/meta.ts (4 hunks)
• daemon/worker.ts (4 hunks)
• daemon/workers/utils.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

daemon/meta.ts (3)

runtime/mod.ts (1)

• meta (106-108)

daemon/worker.ts (2)

• worker (36-52)
• dispatchWorkerState (24-27)

daemon/sse/channel.ts (1)

• broadcast (9-11)

daemon/worker.ts (1)

daemon/workers/denoRun.ts (1)

• DenoRun (48-190)

🔇 Additional comments (9)

daemon/workers/utils.ts (1)

17-48: LGTM! Good observability improvements.

The logging additions provide excellent visibility into port waiting operations, including timing metrics and abort signal status. The timeout formatting change to 10_000 improves readability.

daemon/meta.ts (2)

68-93: LGTM! Excellent hang detection mechanism.

The periodic warning timer provides valuable diagnostics for detecting when meta.promise is taking too long to resolve. The timer is properly cleaned up in the finally block, and the logging includes useful elapsed time metrics.

---

95-154: LGTM! Comprehensive watcher lifecycle logging.

The logging additions provide excellent visibility into the meta watcher's control flow, including attempt tracking, etag values, received metadata, and error conditions. The 404 handling is particularly well-logged before stopping the watcher.

daemon/worker.ts (4)

1-1: LGTM! Good TypeScript typing.

Adding explicit Context and Next types improves type safety throughout the worker middleware.

---

36-52: LGTM! Clear worker lifecycle logging.

The logging provides excellent visibility into the worker startup sequence with timing metrics. This will help diagnose slow worker initialization.

---

72-86: Excellent: Critical error handling prevents startup hangs.

The try-catch wrapper with wp.reject(error) is a crucial addition that prevents indefinite hangs when worker initialization fails. Without this, any code awaiting wp.promise would hang forever on startup errors. The logging also provides clear diagnostics.

---

88-103: LGTM! Good initialization logging and type safety.

The initialization log and explicit type annotations for middleware and handler parameters improve both observability and type safety.

daemon/git.ts (2)

193-226: LGTM! Comprehensive build pipeline logging.

The logging provides excellent visibility into the asynchronous build lifecycle, including timing metrics, buildMap operations, and error conditions. This will help diagnose build issues and track concurrent builds.

---

228-270: Verify that logging author email doesn't violate privacy policies.

The comprehensive logging provides excellent visibility into the publish workflow. However, line 235 logs the author object including the email address. Depending on your organization's privacy policies, logging email addresses (PII) may require additional safeguards or masking.

Consider whether the email should be redacted or if this logging is acceptable under your privacy policies. If PII logging is a concern, apply this diff:

     console.log(
-      `[publish] Author: ${JSON.stringify(author)}, Message: "${message}"`,
+      `[publish] Author: ${author.name}, Message: "${message}"`,
     );