Common Errors

Q: After following the log-in link, why is my screen frozen at /auth?success=true?

Starting with v22.1, Tower Enterprise implements stricter cookie security by default and will only send an auth cookie if the client is connected via HTTPS. The lack of an auth token will cause HTTP-only log-in attempts to fail (thereby causing the frozen screen).

To remediate this problem, set the following environment variable:

 TOWER_ENABLE_UNSAFE_MODE=true.

Q: "Unknown pipeline repository or missing credentials" error when pulling from a public Github repository?

Github imposes rate limits on repository pulls (including public repositories), where unauthenticated requests are capped at 60 requests/hour and authenticated requests are capped at 5000/hour. Tower users tend to encounter this error due to the 60 request/hour cap.

To resolve the problem, please try the following:

1. Ensure there is at least one Github credential in your Workspace's Credentials tab.
2. Ensure that the Access token field of all Github Credential objects is populated with a Personal Access Token value, NOT a user password. (Github PATs are typically several dozen characters long and begin with a ghp_ prefix; example: ghp_IqIMNOZH6zOwIEB4T9A2g4EHMy8Ji42q4HA)
3. Confirm that your PAT is providing the elevated threshold and transactions are being charged against it:

`curl -H "Authorization: token ghp_LONG_ALPHANUMERIC_PAT" -H "Accept: application/vnd.github.v3+json" https://api.github.com/rate_limit`

Some mail services, including Microsoft, have phased out support for TLS 1.0 and 1.1. Tower Enterprise, however, is based on Java 11 (Amazon Coretto) and does not use TLSv1.2 by default. As a result, an encryption error will occur when Tower tries to send email even if you have configured your mail.smtp.starttls settings to be true.

To fix the problem, use this JDK environment variable to force the usage of TLSv1.2 by default:

`_JAVA_OPTIONS="-Dmail.smtp.ssl.protocols=TLSv1.2"`

Q: "Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)" error.

This error can occur if incorrect configuration values are assigned to the backend and cron containers' MICRONAUT_ENVIRONMENTS environment variable. You may see other unexpected system behaviour like two exact copies of the same Nextflow job be submitted to the Executor for scheduling.

Please verify the following:

1. The MICRONAUT_ENVIRONMENTS environment variable associated with the backendcontainer:
   • Contains prod,redis,ha
   • Does not contain cron
2. The MICRONAUT_ENVIRONMENTS environment variable associated with the croncontainer:
   • Contains prod,redis,cron
   • Does not contain ha
3. You do not have another copy of the MICRONAUT_ENVIRONMENTS environment variable defined elsewhere in your application (e.g. a tower.env file or Kubernetes ConfigMap).
4. If you are using a separate container/pod to execute migrate-db.sh, there is no MICRONAUT_ENVIRONMENTS environment variable assigned to it.

Q: "No such variable" error.

This error can occur if you execute a DSL 1-based Nextflow workflow using Nextflow 22.03.0-edge or later.