The demo data creates a credential with no body, so the first time anyone runs one of the demo workflows it fails before the job starts.
The run ends as an exception with this, which reads like the operator forgot to configure something:
CredentialLoadError: Failed to load credential ...: [fetch:credential] Credential environment mismatch.
This project is using 'unknown' but credential 'DHIS2 play' does not have a matching environment.
There is nothing to configure. The credential genuinely has no body at all. select count(*) from credential_bodies comes back zero on a freshly seeded database, while the credential row itself exists.
The cause is that credential bodies moved into their own table with an environment name, and the demo still passes the old shape. Credentials.create_credential builds bodies only from a credential_bodies key, and the demo hands it body, which is dropped on the floor without complaint.
lib/lightning/setup_utils.ex does not mention credential_bodies anywhere, so both of its credential paths are affected: the DHIS2 credential it builds itself, and any credential passed through setup_user.
Worth fixing in two places. The demo should pass a body in the shape the new schema expects, with an environment that matches the project it belongs to. And creating a credential with a body the function ignores should not succeed silently, because that is what turned a seeding bug into a runtime error message pointing the reader at a settings page that cannot help them.
The demo data creates a credential with no body, so the first time anyone runs one of the demo workflows it fails before the job starts.
The run ends as an exception with this, which reads like the operator forgot to configure something:
There is nothing to configure. The credential genuinely has no body at all.
select count(*) from credential_bodiescomes back zero on a freshly seeded database, while the credential row itself exists.The cause is that credential bodies moved into their own table with an environment name, and the demo still passes the old shape.
Credentials.create_credentialbuilds bodies only from acredential_bodieskey, and the demo hands itbody, which is dropped on the floor without complaint.lib/lightning/setup_utils.exdoes not mentioncredential_bodiesanywhere, so both of its credential paths are affected: the DHIS2 credential it builds itself, and any credential passed throughsetup_user.Worth fixing in two places. The demo should pass a body in the shape the new schema expects, with an environment that matches the project it belongs to. And creating a credential with a body the function ignores should not succeed silently, because that is what turned a seeding bug into a runtime error message pointing the reader at a settings page that cannot help them.