[nealrichardson]

Remove the legacy numeric content ID path (app_get, get_content_by_id, ContentItemV0) and use content_get directly. An explicit --app-id for a Connect target must be a content GUID.

Add --guid to the deploy commands and preflight as the Connect-specific way to target existing content. It conflicts with --app-id and --new, and is rejected for Connect Cloud and shinyapps.io targets.

Connect in Snowflake (SPCS) now goes through the same GUID lookup, which fixes --app-id against SPCS (it previously failed with "Unable to infer Connect client.").

Fixes #881
Fixes #885

🤖 Generated with Claude Code

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-11-05 22:46 UTC

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
11034	9771	89%	0%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
rsconnect/api.py	90%	🟢
rsconnect/main.py	87%	🟢
rsconnect/models.py	93%	🟢
rsconnect/preflight.py	87%	🟢
rsconnect/preflight_node.py	91%	🟢
TOTAL	90%	🟢

updated for commit: 34071e1 by action🐍

[joshyam-k]

this all makes sense to me. only consideration that comes to mind is what kind of a version bump we should go with in the release given that this is a breaking change. It's not a huge change and there are instructions for what to do differently, but this will break scripts that rely on the prior behavior.

[mconflitti-pbc]

Looks good!

Two minor things to consider:

1. Numeric IDs from saved deployment records skip the GUID check. validate_explicit_app_id() checks only an explicit --app-id or --guid. In validate_app_mode(), an app_id that comes from app_store.resolve() gets no check. If an old deployment record has only a numeric app_id and no app_guid, a redeploy with no --app-id calls content_get("1234"). That call fails with a 404 and a "try --new" hint, but this path works on main today. You could apply the same GUID check to IDs from the record for Connect, with an error that names --guid or --new. Or you could note this case in the CHANGELOG. Records like this might not exist in practice.

2. The SPCS --app-id behavior changes, but the CHANGELOG and tests do not show it. On main, SPCS with --app-id fails with "Unable to infer Connect client." because the isinstance check in validate_app_mode() does not include SPCSConnectServer. This PR fixes that path. A CHANGELOG line and a test would make the fix visible.

[nealrichardson]

Looks good!

Two minor things to consider:

1. Numeric IDs from saved deployment records skip the GUID check. validate_explicit_app_id() checks only an explicit --app-id or --guid. In validate_app_mode(), an app_id that comes from app_store.resolve() gets no check. If an old deployment record has only a numeric app_id and no app_guid, a redeploy with no --app-id calls content_get("1234"). That call fails with a 404 and a "try --new" hint, but this path works on main today. You could apply the same GUID check to IDs from the record for Connect, with an error that names --guid or --new. Or you could note this case in the CHANGELOG. Records like this might not exist in practice.

This is not a real concern in practice. The "app store" has included app_guid since it was first introduced, so there should be no record that doesn't have a guid.

2. The SPCS --app-id behavior changes, but the CHANGELOG and tests do not show it. On main, SPCS with --app-id fails with "Unable to infer Connect client." because the isinstance check in validate_app_mode() does not include SPCSConnectServer. This PR fixes that path. A CHANGELOG line and a test would make the fix visible.

Thanks, fix pushed.