When Kaisin fails
Every answer the Kaisin connector can give, and where each one sends you.
A failed push or a failed connect leaves a sentence on the row and keeps the environment marked as owing one. Nothing is lost and nothing retries into silence: the worker backs off, and the bell says so if it stays broken.
Each of these is a different problem with a different fix, which is why they are not one message.
“That address is not a Kaisin, or its Kaisin is older than the version that can connect apps.”
orcakey.sh checks the address before sending your browser to it. Either nothing Kaisin-shaped answered there, or it answered but does not speak the integration API this connector needs. Check the address, and check that Kaisin is on a version that supports connecting apps.
“That Kaisin says it lives at {address}. Connect using that address instead.”
The address you typed answered, but told orcakey.sh that its own approval and token endpoints live at a different address. orcakey.sh will only ever send a code or a grant to the address you typed, so it refuses rather than following that redirection. Connect again using the address Kaisin itself named.
“Kaisin did not accept the approval. Connect again.”
The code from the consent page was wrong, already used, expired, or meant for a different request. Kaisin gives one answer for all four on purpose, since the fix is the same either way: start the connection again from Integrations → Kaisin.
“Kaisin revoked orcakey.sh’s access. Reconnect from Integrations → Kaisin.”
The grant was revoked from Kaisin’s side, under Settings → Connected apps. Every connection through this workspace fails until you reconnect, which is a fresh approval on Kaisin’s consent page, and issues a new grant.
“Kaisin already has KEY, set by a person. Delete it in Kaisin to let orcakey.sh manage it.”
A push tried to set KEY, but Kaisin already has a variable by that name that
a person set by hand. orcakey.sh never overwrites or adopts it: this key is
left alone, and every other key in the push still lands. Delete the
person-set variable in Kaisin to let orcakey.sh take over the name, or rename
the key in orcakey.sh.
“Kaisin already has KEY, left from an earlier connection to orcakey.sh. Delete it in Kaisin to let orcakey.sh manage it again.”
After a disconnect, the variables orcakey.sh had written stay in Kaisin and become editable. Connecting again does not take them back on its own, because somebody may have edited one since. Delete the ones orcakey.sh should manage again, and the next push writes them.
“Kaisin supplies KEY from <name>; remove it from the collection or detach the resource.”
The same collision, but the existing value comes from an attached resource
(a database, for instance) rather than a person. Either remove KEY from the
collection feeding this connection, or detach the resource in Kaisin so the
name is free.
“Kaisin no longer has that project, application or environment.”
The Kaisin project, application or environment this connection points at was deleted. The row keeps the last name it read. Re-align the project, or reconnect the environment, to point it at what exists now.
“Kaisin could not be reached: …”
orcakey.sh could not reach the address at all — the workspace moved, is down, or the network between the two will not carry the request. The worker retries on its schedule, and a retry sends the same complete set, so a write that did land the first time changes nothing the second; if the address itself changed, reconnect at the new one.
A push that lands but does not roll out
If the write itself succeeds but Kaisin’s rollout fails, the connection
is still live — the values are exactly where they should be. The
failed build or deploy is Kaisin’s own to report, on the application
the row’s Open ↗ link opens.