Skip to content
Semaloop Docs

Common errors

Here are some of the most common errors we see in Semaloop, and how to avoid them:

  • Agents lose access to your build. If you’ve chosen to connect your application via TestFlight, this usually happens when agents are removed from your TestFlight group, invites run out, or a new version ships to a different track. We uninstall the app after every run, so losing TestFlight access means losing access entirely. Keep all agents in your group and on the track you want tested.
  • .ipa signing failures. If you’ve connected your app pushing builds via CLI rather than TestFlight, real-device runs require the .ipa to be signed with Semaloop device UDIDs before you upload. A build signed without those UDIDs uploads fine but fails to install at run time. Contact us to get our UDID list.
  • Not enough sandbox accounts. Sandbox accounts are claimed exclusively per concurrent run, so if you’re running more parallel tests than you’ve provisioned sandbox accounts for, later runs queue or fail waiting for one to free up. Provision sandbox accounts to match your peak concurrency, not your average.
  • Secret not assigned to a test. A test referencing a secret in its spec (e.g. “log in with a premium account”) will fail if that secret hasn’t been explicitly assigned to the test in the test editor. The secrets manager holding the value isn’t enough on its own, and assignment is a separate required step.
  • Credential contention across parallel runs. Because agents never reuse the same credentials from the secrets manager across tests running in parallel, too few credentials in a secret relative to your concurrent run count bottlenecks tests waiting for one to free up.