Collaborator source RMD publishing creates a new app instead of a new bundle

[dbkegley]

rsconnect: 1.1.0
Connect: 2023.10.0-dev+216-g70573d7869

1. Add Admin and Publisher users as connections in the IDE
2. Deploy an RMD (with source) as the Admin from the IDE
3. Add the Publisher as a collaborator in the Connect dashboard
4. In the IDE, remove the Admin user connection
5. Re-deploy the same RMD (with source) as the Publisher from the IDE

actual:
A new App is created (owned by the Publisher)

expected:
A new bundle should be created for the existing App (owned by the Admin)

see also: https://docs.posit.co/tutorials/user/publishing-with-collaboration-on-rsc/ (obsolete)
see also: https://docs.posit.co/connect/user/publishing/#publishing-collaboration

[dbkegley]

We have also seen this bug in Version: 1.0.1 so it may have been introduced initially with the 1.0.0 refactoring

[toph-allen]

You can work around this issue by using the appID argument to rsconnect::deployApp(), e.g.

rsconnect::deployApp(appDir = ".", appId = "a2859a31-4326-4125-9deb-39f31e5d4fbc")

[aronatkins]

The v0.8.29 release falls into this clause when determining the deployment target:

rsconnect/R/deployApp.R

Lines 681 to 686 in 9ce427e

	# both appName and account explicitly specified
	if (!is.null(appName) && !is.null(account)) {
	accountDetails <- accountInfo(account, server)
	createDeploymentTarget(appName, appTitle, appId, accountDetails$username,
	account, accountDetails$server)
	}

The IDE calls deployApp() using the content name from the previous deployment, but uses the account associated with the (local) collaborator account. I have not uncovered how the IDE determines which account to provide when calling deployApp().
https://github.com/rstudio/rstudio/blob/afbabb533c00add040c124126438177457ba5592/src/cpp/session/modules/SessionRSConnect.cpp#L280

[aronatkins]

When the IDE recognizes that the target deployment does not correspond with an account that is configured, it attempts to discover a local account on the same server. As a result, rsconnect::deployApp() can be called with the original content name and server but a different account.

https://github.com/rstudio/rstudio/blob/afbabb533c00add040c124126438177457ba5592/src/gwt/src/org/rstudio/studio/client/rsconnect/ui/RSConnectDeploy.java#L760-L796

rsconnect::deployApp() needs to use name and server, but ignore app, to correctly target these deploys.

[hadley]

Would it be useful to have a function that detects when deployApp() is being called by RStudio? Then we could make the IDE specific logic more clear.

[aronatkins]

Related: When targeting a deployment, there are two accounts:

1. The original account that created the content.
2. The current account attempting to update the content.

With 0.8.29, these concepts were (mostly) separate, though not obviously so. The distinction between these two accounts was lost with 1.0.0.

We will need deploymentTarget to indicate the updating account without modifying the deployment record.

[aronatkins]

Would it be useful to have a function that detects when deployApp() is being called by RStudio? Then we could make the IDE specific logic more clear.

I do not believe that we need to understand when we are being called by the IDE. I think the mistake was not understanding that the incoming account might not match the account on the deployment record. That expectation was very subtle in the 0.8.29 workflow. I'm actively trying to make that more explicit.

[aronatkins]

We believe that this problem is resolved in the development version of rsconnect.

remotes::install_github("rstudio/rsconnect")