The problem
A plugin field write naming a virtual field passes both of the guards added to refuse unknown fields — the field is declared, so both lookups succeed — and then falls through to a write carrying that field name as a column.
The field has no column, so the database rejects it with its own error type, which is not in the set of names the RAG hook treats as a refusal. The failure is therefore reported through the retryable path, advising the caller to retry by writing the source field again. Retrying cannot help, because the field will never have a column.
Reproduced directly.
A related suspicion was checked and cleared in the same pass: a relationship field behaves correctly, its foreign key moving as expected. Recorded so nobody re-investigates it.
What to do
Refuse a field with no columns by name, alongside the existing refusals for an undeclared list and an undeclared field. The message should say what is wrong — a virtual field has nothing to write to — rather than leaving the caller with a database error about an unknown column.
While there, reconsider whether the database's own error type belongs in the refusal set. It is currently absent, which is why this case and, before it was fixed, three others were misreported as transient. Adding it would be a second line of defence, though refusing by name at the boundary is the better primary fix.
Context
_Generated by Claude Code
The problem
A plugin field write naming a virtual field passes both of the guards added to refuse unknown fields — the field is declared, so both lookups succeed — and then falls through to a write carrying that field name as a column.
The field has no column, so the database rejects it with its own error type, which is not in the set of names the RAG hook treats as a refusal. The failure is therefore reported through the retryable path, advising the caller to retry by writing the source field again. Retrying cannot help, because the field will never have a column.
Reproduced directly.
A related suspicion was checked and cleared in the same pass: a relationship field behaves correctly, its foreign key moving as expected. Recorded so nobody re-investigates it.
What to do
Refuse a field with no columns by name, alongside the existing refusals for an undeclared list and an undeclared field. The message should say what is wrong — a virtual field has nothing to write to — rather than leaving the caller with a database error about an unknown column.
While there, reconsider whether the database's own error type belongs in the refusal set. It is currently absent, which is why this case and, before it was fixed, three others were misreported as transient. Adding it would be a second line of defence, though refusing by name at the boundary is the better primary fix.
Context
_Generated by Claude Code