configuration.move_read_unsupported

A constant jadpo config move was asked to make a setting is read where a setting can't be: in a query, an update by id, a backfill or another constant's value.

Area 14, Tools; not declinable; the next step is usually the agent's.

Why Jadpo refuses it

jadpo config move <constant> turns a constant into a setting and rewrites every read of it to config.<name>. A setting is known only when the application starts. A query, an update by id and a backfill are worked out by the database, and another constant's value while compiling, so none of them can read one. The move would leave code that doesn't check, so it refuses, names every such read, and changes nothing.

What it looks like

A library in the accounts domain works out when to warn from the number of sign-ins before an account is locked:

domains/accounts/libraries/security.jadpo:

use accounts/types { LoginAttempts }library security {    /// Failed sign-ins before an account is locked.    constant max_login_attempts: LoginAttempts = 5    /// Failed sign-ins before a warning is shown.    constant warn_after: LoginAttempts = LoginAttempts(max_login_attempts - 2)}

jadpo config move security.max_login_attempts

  |7 |     constant warn_after: LoginAttempts = LoginAttempts(max_login_attempts - 2)  |                                                        ^^^^^^^^^^^^^^^^^^ in a constant's value

(agent) at the end of the next: line means your coding agent can make the fix itself.

A read in a query, an update by id or a backfill is refused the same way, with what to pass instead.

How to fix it

If the warning should be a setting too, make it one first, then the constant it reads:

jadpo config move security.warn_afterjadpo config move security.max_login_attempts

config.jadpo then has both settings, warn_after with the value it had, 3, as its default:. A deployment sets each on its own, as WARN_AFTER and MAX_LOGIN_ATTEMPTS.

If it should stay fixed, write its value out:

library security {    ...    constant warn_after: LoginAttempts = 3}

jadpo config move security.max_login_attempts then makes it a setting, and the warning stays at 3 whatever a deployment sets.

Related

• Making a constant a setting
• jadpo config move