Workspaces

Q: Why is my Tower-invoked pipeline trying to contact a different Workspace than the one it was launched from?

This problem creates an entry in your Nextflow log similar to this: Unexpected response for request http://YOUR_TOWER_URL/api/trace/TRACE_ID/begin?workspaceId=WORKSPACE_ID.

This can occur because:

1. An access token value has been hardcoded in the tower.accessToken block of your nextflow.config (either via the git repository itself or override value in the launch form).
2. In cases where your compute environment is an HPC cluster, the credentialized user's home directory contains a stateful nextflow.config with a hardcoded token (e.g. `~/.nextflow/config).

Q: What privilege level is granted to a user assigned to a Workspace both as a Participant and Team member?

It is possible for a user to be concurrently assigned to a Workspace both as a named Participant and member of a Team. In such cases, Tower will grant the higher of the two privilege sets.

Example:

• If the Participant role is Launch and the Team role is Admin, the user will have Admin rights.
• If the Participant role is Admin and the Team role is Launch, the user will have Admin rights.
• If the Participant role is Launch and the Team role is Launch, the user will have Launch rights.

As a best practice, we suggest using Teams as the primary vehicle for assigning rights within a Workspace and only adding named Participants when one-off privilege escalations are deemed necessary.