Skip to content

ALC-1005: Transaction outcome unknown

The connection dropped while Alcuin was committing your changes, and Alcuin could not find out whether the commit landed. Your changes stay staged so nothing is lost while you check.

For staged row changes, the bar under the grid shows one of:

  • The connection dropped while committing. Reload the rows to see whether the changes landed; applying them again checks first.
  • The server cannot yet say whether the last commit of these changes landed. Try again in a moment.
  • The server no longer knows whether the last commit of these changes landed. Reload the rows to check; applying them again sends them anyway.

When the commit that went missing was an earlier one, with other changes, the bar says so instead. The first shows while the server cannot answer yet; the second only when your staged changes hold a new row that the earlier commit may have added. Otherwise Alcuin runs your changes, and an update of a row that commit changed fails as stale (ALC-3002).

  • The server cannot yet say whether an earlier commit, whose reply was lost, landed. Try again in a moment.
  • The server no longer knows whether an earlier commit, whose reply was lost, added the new row staged here. Reload the rows to check; applying them again sends them anyway. (added new rows staged here for more than one)

For staged structure changes and scripts, the review shows one of:

  • The connection dropped while committing. Reload to see whether the changes landed; applying them again checks first. When the changes run in steps and some had already committed, it adds, for example, 1 of 2 steps were already applied and stay.
  • The server cannot yet say whether the last commit of these changes landed. Try again in a moment.
  • The server no longer knows whether the last commit of these changes landed. Reload to check; applying them again sends them anyway.

For grant changes, it shows:

  • The connection dropped while committing. Reload to see whether the changes landed.

A CSV import and Seed data say the same in their own words, such as The connection dropped while the import was committing, so whether it landed is unknown. Check orders; the next import into it asks the server first. or The connection dropped while committing. Reload to see whether the rows landed.

The connection lost banner usually appears at the same time.

Alcuin sent COMMIT, and the connection dropped before the server’s answer arrived. The commit may have landed or not; only the server knows.

For row changes, structure changes and scripts, Alcuin writes down the transaction’s id, and the server it runs on, before it sends COMMIT, so the note survives Alcuin itself stopping. When the answer goes missing, it asks that server how the transaction ended. You see this error when the server cannot answer yet, usually because it is still unreachable.

A server keeps the outcome of a transaction only for so long, and a statement a script runs outside a transaction has no id to ask about. When the server can no longer say, Alcuin tells you once, then sends the changes if you apply them again. If the connection now points at a different server, Alcuin leaves the note alone and asks nothing of the new one.

  1. Wait for the connection to come back.
  2. Commit again. Before anything runs, Alcuin asks the server how the earlier commit ended:
    • If it landed and you changed nothing since, nothing is applied twice. A toast says These changes were already applied., Alcuin clears the staged changes and reads the rows again (ALC-3003).
    • If it did not land, Alcuin applies the changes now.
    • If the server still cannot say, you see The server cannot yet say… again. Wait a moment and commit again.
    • If the server no longer knows, you see The server no longer knows…. Look at the rows Alcuin read again; if the changes are not there, commit again to send them.

If you edited a staged change before committing again, it is a different set, and Alcuin still asks first. When the earlier commit landed:

  • A new row it already added is not added again. Alcuin applies nothing, takes that row out of your staged changes and reads the rows again (ALC-3007).
  • An edited update or delete of a row the earlier commit already changed fails as stale, since the row is no longer the version you loaded (ALC-3002). Review it, or discard it and reload.
  1. Wait for the connection to come back.
  2. Apply again. Alcuin asks the server first: if every step landed, it says the changes were already applied; if some did, it says how many stay and runs nothing again (ALC-3007); if none did, it applies them.

Alcuin does not check these before applying them again, so look first.

  1. Wait for the connection to come back.
  2. Click Refresh objects in the object tree, then look at the role’s grants.
  3. If the change is there, click Discard changes: it already landed.
  4. If it is not there, apply the changes again.

The engine reports this as ENGINE_TX_UNKNOWN. Quote either name in an issue.