Skip to content

Conversation

@devin-ai-integration
Copy link
Contributor

@devin-ai-integration devin-ai-integration bot commented Dec 30, 2025

fix: improve deployment failure diagnostics and error reporting

Summary

This PR improves the CLI's handling of deployment failures to provide users with more actionable information when deployments fail. Previously, users would only see "Your deployment failed to start" with no context about where to look for more information.

Key changes:

  1. Added .passthrough() to DeploymentStatusObject schema for forward compatibility - if the backend adds error fields in the future, they won't be stripped by Zod

  2. Improved error output to always show on failure:

    • Deployment ID
    • Dashboard URL (clickable link)
    • Guidance when no warmup logs are received
  3. Upgraded stream logging from trace to debug level so users can see stream connection failures with --log-level=debug

Updates since last revision

Per reviewer feedback, removed speculative error fields (error, reason, message, code, traceId) from the schema since the backend doesn't currently return them. Also removed the DeploymentFailedError structured error type. The PR now focuses only on improvements supported by actual data: showing deployment ID, dashboard URL, and guidance on failure.

Review & Testing Checklist for Human

  • Verify dashboard URL is correct: The URL pattern ${appUrl}/r/${deployment.id} should link to the deployment details page - please verify this is the correct format
  • Test with a real deployment failure: Deploy a project that will fail and verify the deployment ID and dashboard URL are displayed
  • Verify guidance message: When no logs are received, the message suggests --log-level=trace - confirm this is the right advice

Recommended test plan:

  1. Create a project that will fail on startup (e.g., reference undefined env var)
  2. Run agentuity deploy and observe the error output
  3. Verify the deployment ID and dashboard URL are displayed
  4. Click the dashboard link to confirm it goes to the right page

Notes

This is a minimal, low-risk change that improves UX on deployment failures by always showing the deployment ID and dashboard link, helping users debug issues.

Fixes #329

Link to Devin run: https://app.devin.ai/sessions/592577b9d85643f6a27089a5baec18fa
Requested by: penrique@agentuity.com (@pec1985)

Summary by CodeRabbit

  • Bug Fixes

    • Improved error reporting for failed deployments — shows Deployment ID and Dashboard URL and prints deployment-specific info on failure.
    • Enhanced guidance when no warmup logs are received (suggests re-running with higher log-level or checking the dashboard).
  • Improvements

    • Deployment status responses now accept additional fields, allowing richer status metadata.

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

This commit improves the CLI's handling of deployment failures by:

1. Adding forward-compatible optional error fields to DeploymentStatusObject:
   - error, reason, message, code, traceId
   - Using .passthrough() to allow additional fields from backend

2. Creating DeploymentFailedError structured error to carry failure details

3. Improving error handling in the catch block:
   - Display error/reason/message from backend if available
   - Always show deployment ID and dashboard URL on failure
   - Show trace ID if available for debugging
   - Provide guidance when no warmup logs are received

4. Upgrading stream connection failure logging from trace to debug level

Fixes #329

Co-Authored-By: penrique@agentuity.com <pedro.tma@gmail.com>
@devin-ai-integration
Copy link
Contributor Author

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment and CI monitoring

@coderabbitai
Copy link

coderabbitai bot commented Dec 30, 2025

📝 Walkthrough

Walkthrough

CLI deployment failure handling and diagnostics messages were adjusted (log levels, failure guidance, and when/what to display). Server deployment status schema now allows extra properties by adding .passthrough() to the DeploymentStatusObject.

Changes

Cohort / File(s) Summary
CLI deploy flow
packages/cli/src/cmd/cloud/deploy.ts
Changed two trace-level logs to debug for warmup log stream errors; on deployment start failure now prints Deployment ID and Dashboard URL (when available); emits warning if no warmup logs and guides to re-run with --log-level=trace or check dashboard; writes existing logs to file and shows last lines when present.
Server deployment status schema
packages/server/src/api/project/deploy.ts
Added .passthrough() to DeploymentStatusObject so extra properties are allowed on deployment status responses; exported types (DeploymentStatusObjectSchema, DeploymentStatusResponse, DeploymentStatusResult) remain defined.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check ✅ Passed The PR comprehensively addresses issue #329 by surfacing backend error details, adding deployment ID/dashboard URL, and improving log visibility for stream failures.
Out of Scope Changes check ✅ Passed All changes are directly scoped to deployment failure diagnostics: error handling improvements in CLI, schema modifications for backend field passthrough, and user-facing guidance enhancements.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch devin/1767098222-improve-deploy-failure-diagnostics

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b437c32 and e667fb1.

📒 Files selected for processing (2)
  • packages/cli/src/cmd/cloud/deploy.ts
  • packages/server/src/api/project/deploy.ts
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/server/src/api/project/deploy.ts
  • packages/cli/src/cmd/cloud/deploy.ts

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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
packages/cli/src/cmd/cloud/deploy.ts (1)

679-685: Consider suggesting --log-level=debug for consistency.

Line 683 suggests re-running with --log-level=trace, but the stream connection logs were raised to debug level (lines 524, 554). Users running with --log-level=debug should see connection issues.

🔎 Proposed adjustment
 				tui.newline();
 				tui.warning(
-					'No warmup logs were received. Try re-running with --log-level=trace or check the dashboard for runtime errors.'
+					'No warmup logs were received. Try re-running with --log-level=debug or check the dashboard for runtime errors.'
 				);
📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d7c0962 and b437c32.

📒 Files selected for processing (2)
  • packages/cli/src/cmd/cloud/deploy.ts
  • packages/server/src/api/project/deploy.ts
🧰 Additional context used
📓 Path-based instructions (6)
packages/cli/src/cmd/**/*.ts

📄 CodeRabbit inference engine (packages/cli/AGENTS.md)

packages/cli/src/cmd/**/*.ts: Use tui.* helpers for formatted output instead of raw console logs
Use ctx.logger for logging; call logger.fatal() to log and exit with code 1

Files:

  • packages/cli/src/cmd/cloud/deploy.ts
packages/cli/src/**/*.ts

📄 CodeRabbit inference engine (packages/cli/AGENTS.md)

Use Bun.file(f).exists() instead of existsSync(f) for file existence checks

Files:

  • packages/cli/src/cmd/cloud/deploy.ts
**/*.{ts,tsx,js,jsx,json}

📄 CodeRabbit inference engine (AGENTS.md)

Use Prettier for code formatting with tabs (width 3), single quotes, and semicolons

Files:

  • packages/cli/src/cmd/cloud/deploy.ts
  • packages/server/src/api/project/deploy.ts
**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Use TypeScript strict mode with ESNext target and bundler moduleResolution

Files:

  • packages/cli/src/cmd/cloud/deploy.ts
  • packages/server/src/api/project/deploy.ts
**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{ts,tsx,js,jsx}: Use StructuredError from @agentuity/core for error handling
Ensure all errors AND warnings must be zero before committing

Files:

  • packages/cli/src/cmd/cloud/deploy.ts
  • packages/server/src/api/project/deploy.ts
packages/server/src/**/*.ts

📄 CodeRabbit inference engine (packages/server/AGENTS.md)

packages/server/src/**/*.ts: All code must be runtime-agnostic - no Bun-specific or Node-specific APIs
All code must be TypeScript (TypeScript-first approach)
Prefer interfaces for public APIs
No browser APIs allowed - server-side only code

Files:

  • packages/server/src/api/project/deploy.ts
🧠 Learnings (3)
📚 Learning: 2025-12-21T00:31:41.858Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 274
File: packages/cli/src/cmd/build/vite/server-bundler.ts:12-41
Timestamp: 2025-12-21T00:31:41.858Z
Learning: In Bun runtime, BuildMessage and ResolveMessage are global types and are not exported from the bun module. Do not import { BuildMessage } from 'bun' or similar; these types are available globally and should be used without import. This applies to all TypeScript files that target the Bun runtime within the repository.

Applied to files:

  • packages/cli/src/cmd/cloud/deploy.ts
  • packages/server/src/api/project/deploy.ts
📚 Learning: 2025-12-19T14:19:33.765Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 259
File: packages/cli/src/cmd/build/vite/registry-generator.ts:306-312
Timestamp: 2025-12-19T14:19:33.765Z
Learning: Route files under src/api should use the .ts extension only (no .tsx) and regex patterns for such paths should anchor to \.ts$ (e.g., /\/.ts$/). Agent files may support both .ts and .tsx, but route files in the Agentuity SDK codebase are restricted to .ts. This guideline applies to all similar route files under src/api across the repository.

Applied to files:

  • packages/server/src/api/project/deploy.ts
📚 Learning: 2025-12-30T00:13:37.849Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 355
File: packages/server/src/api/sandbox/util.ts:2-6
Timestamp: 2025-12-30T00:13:37.849Z
Learning: In the packages/server tree, treat code as runtime-agnostic between Node.js and Bun. Ensure TypeScript files (e.g., util.ts) import and use APIs in a way that works under both runtimes. It is acceptable to rely on Bun’s Node.js compatibility for built-ins accessed via the node: namespace (e.g., node:events, node:stream, node:buffer). During reviews, prefer patterns and imports that remain compatible with Bun's environment, and flag any hard dependencies on runtime-specific globals or non-portable Node APIs.

Applied to files:

  • packages/server/src/api/project/deploy.ts
🔇 Additional comments (7)
packages/server/src/api/project/deploy.ts (1)

268-278: LGTM! Schema extension follows best practices.

The addition of optional diagnostic fields (error, reason, message, code, traceId) and .passthrough() provides forward-compatible error diagnostics. The schema is well-annotated and maintains consistency with existing patterns.

packages/cli/src/cmd/cloud/deploy.ts (6)

54-61: LGTM! Structured error follows best practices.

The DeploymentFailedError definition correctly uses StructuredError from @agentuity/core (as per coding guidelines) and includes all relevant diagnostic fields from the server-side schema.


524-526: LGTM! Log level elevation improves diagnostics.

Raising stream connection failures from trace to debug aligns with the PR objective to make deployment diagnostics more visible when users run with --log-level=debug.

Also applies to: 554-554


580-589: LGTM! Error construction captures all diagnostic details.

The DeploymentFailedError is correctly constructed with all available diagnostic fields from the status response, enabling rich error reporting downstream.


616-641: Verify the error message construction on Line 637.

The conditional on lines 634-636 checks for exwithmessage.message, but line 637 calls exwithmessage.toString(). This may not produce the intended error message.

Consider using the message property directly for consistency:

🔎 Proposed fix
 			} else {
 				const exwithmessage = ex as { message: string };
 				if (
 					exwithmessage.message &&
 					exwithmessage.message !== 'Deployment failed'
 				) {
-					errorMsg = exwithmessage.toString();
+					errorMsg = exwithmessage.message;
 				}
 			}

643-658: Verify the dashboard URL pattern.

The dashboard URL is constructed as ${appUrl}/r/${deployment.id}. The PR checklist mentions confirming this URL pattern matches the actual dashboard routing.

Please verify that the /r/{deploymentId} path is the correct route for the deployment dashboard.


712-719: LGTM! Non-streaming path mirrors streaming implementation.

The non-streaming polling path correctly throws DeploymentFailedError with all diagnostic fields, maintaining consistency with the streaming path (lines 580-589).

reason?: string;
message?: string;
code?: string;
traceId?: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where is traceId coming from? we use sessionId (and the response HTTP header x-session-id) for session information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right - I've removed the speculative error fields (error, reason, message, code, traceId) from the schema since the backend doesn't currently return them. I've also removed the DeploymentFailedError structured error type.

The PR now keeps only the improvements that are supported by actual data:

  • Always show deployment ID on failure
  • Always show dashboard URL on failure
  • Show guidance when no warmup logs are received
  • Keep .passthrough() on the schema for forward compatibility (so if the backend adds fields later, they won't be stripped)
  • Upgraded stream logging from trace to debug level

Thanks for the feedback!

reason: statusResult.reason,
message: statusResult.message,
code: statusResult.code,
traceId: statusResult.traceId,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where is this coming from?


// Show trace ID if available for debugging
if (ex instanceof DeploymentFailedError && ex.traceId) {
tui.info(`Trace ID: ${ex.traceId}`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be Session ID: session_id

Not trace id

- Remove error, reason, message, code, traceId fields from DeploymentStatusObject
- Remove DeploymentFailedError structured error type
- Keep .passthrough() for forward compatibility
- Keep supported improvements: deployment ID, dashboard URL, guidance on no logs

Co-Authored-By: penrique@agentuity.com <pedro.tma@gmail.com>
@jhaynie
Copy link
Member

jhaynie commented Dec 30, 2025

you basically just removed all the code that you created in this PR. i made a comment about getting the session id from the response but you ended up removing a ton of code.

Copy link
Member

@jhaynie jhaynie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i will need to take this over and clean it up. display the dashboard url and deployment id inline with break the box.

@jhaynie jhaynie added the Do Not Merge This is not ready to merge label Dec 30, 2025
@devin-ai-integration
Copy link
Contributor Author

I apologize for the misunderstanding. I interpreted your questions about "where is this coming from?" as meaning I should remove the speculative fields entirely, when you were actually asking me to:

  1. Rename traceId to sessionId and get it from the x-session-id response header
  2. Keep the structured error handling but align with the actual backend contract
  3. Display the deployment ID and dashboard URL inline with the error box (not as separate tui.info() lines)

I'm happy to restore the code and implement it correctly if you'd like, or you can take it over. Let me know what you prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Do Not Merge This is not ready to merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deployment failed

3 participants