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.
What you see
Section titled “What you see”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 herefor 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.
Why it happens
Section titled “Why it happens”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.
What to do
Section titled “What to do”Staged row changes
Section titled “Staged row changes”- Wait for the connection to come back.
- 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 it landed and you changed nothing since, nothing is applied twice. A toast says
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.
Staged structure changes and scripts
Section titled “Staged structure changes and scripts”- Wait for the connection to come back.
- 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.
Staged grant changes
Section titled “Staged grant changes”Alcuin does not check these before applying them again, so look first.
- Wait for the connection to come back.
- Click Refresh objects in the object tree, then look at the role’s grants.
- If the change is there, click Discard changes: it already landed.
- If it is not there, apply the changes again.
Internal name
Section titled “Internal name”The engine reports this as ENGINE_TX_UNKNOWN. Quote either name in an issue.