ALC-3003: Changes already applied

Alcuin refused to apply a set of changes because the same set was already committed. Each set of staged changes carries an id made from what the changes say, so a repeat, such as a retry after a lost reply, is never applied twice.

What you see

A toast reads These changes were already applied. Alcuin treats the set as committed: it clears the staged changes, reads the rows again for row changes, and refreshes the object tree for structure, grant and policy changes.

A CSV import that already ran says so in the import screen instead: This import already ran. Reload orders to see its rows., or This import landed when the connection dropped. Reload orders to see its rows.

Why it happens

• You committed the same set again, for example after the reply to the first commit went missing.
• The connection dropped during a commit, and when you committed again Alcuin asked the server and found the first commit had landed.

What to do

Nothing. Look at the rows, the table’s structure or the role’s grants to confirm your change is there.

If you edited a staged change after the first commit and before committing again, it is a different set, and this error does not stop it. Alcuin still asks the server how the first commit ended before running it. When it had landed:

• A new row it already added is not added again: Alcuin applies none of the edited set, takes that row out of the staged changes and reads the rows again (ALC-3007).
• An edited update or delete of a row the first commit already changed fails as stale, because the row is no longer the version you loaded (ALC-3002).

While the server cannot yet say how the first commit ended, you see ALC-1005 instead. When it no longer knows, Alcuin says so only if your set holds a new row that commit may have added (ALC-1005). Otherwise it runs your set, and an update or delete of a row that commit changed fails as stale.

Internal name

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