null value in column "data" of relation "changes" violates not-null constraint

[krainboltgreene]

While running the application the library works, but in tests it fails with this error even when we turn on capture: :ignore.

     ** (Postgrex.Error) ERROR 23502 (not_null_violation) null value in column "data" of relation "changes" violates not-null constraint

         table: changes
         column: data

     Failing row contains (154, 6012496, insert, public, merchants, null, null, {}, 5993165, null).

[maltoe]

Good day to you, too, @krainboltgreene

Carbonite's trigger procedures shouldn't be setting the changes.data column to anything but a jsonb value. Can you give me a little more information about your scenario? Trigger config, table schema, test setup, etc. Ideally a minimal working example reproducing the crash.

[krainboltgreene]

Absolutely I can get you those details.

[krainboltgreene]

So I have no idea what we did differently, maybe it was updating elixir, erlang, ecto, and/or postgres, but now it completely works in tests.

[krainboltgreene]

Unfortunately it's happening again, so let me try and get you as much information as possible:

     ** (Postgrex.Error) ERROR 23502 (not_null_violation) null value in column "data" of relation "changes" violates not-null constraint

         table: changes
         column: data

     Failing row contains (155, 6430169, insert, public, merchants, null, null, {}, 6410293, null).
     stacktrace:
       (ecto_sql 3.12.1) lib/ecto/adapters/sql.ex:1096: Ecto.Adapters.SQL.raise_sql_call_error/1
       (ecto 3.12.4) lib/ecto/repo/schema.ex:834: Ecto.Repo.Schema.apply/4
       (ecto 3.12.4) lib/ecto/repo/schema.ex:415: anonymous fn/15 in Ecto.Repo.Schema.do_insert/4
       (ecto 3.12.4) lib/ecto/multi.ex:897: Ecto.Multi.apply_operation/5
       (elixir 1.17.3) lib/enum.ex:2531: Enum."-reduce/3-lists^foldl/2-0-"/3
       (ecto 3.12.4) lib/ecto/multi.ex:870: anonymous fn/5 in Ecto.Multi.apply_operations/5
       (ecto_sql 3.12.1) lib/ecto/adapters/sql.ex:1400: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
       (db_connection 2.7.0) lib/db_connection.ex:1756: DBConnection.run_transaction/4
       (ecto 3.12.4) lib/ecto/repo/transaction.ex:18: Ecto.Repo.Transaction.transaction/4
       (core 1.0.0) test/support/fixtures/users_fixtures.ex:104: Dashboard.UsersFixtures.active_merchant_fixture/1
       test/dashboard/transactions/refund_demand_test.exs:5: Dashboard.Transactions.RefundDemandTest.__ex_unit_setup_1/1
       test/dashboard/transactions/refund_demand_test.exs:1: Dashboard.Transactions.RefundDemandTest.__ex_unit__/2

Interestingly there is a change happening in this transaction.

Here's the log of SQL:

16:25:32.312 [debug] QUERY OK db=0.1ms
begin []
16:25:32.320 [debug] QUERY OK source="transactions" db=4.7ms
INSERT INTO "carbonite_default"."transactions" ("meta","inserted_at") VALUES ($1,$2) ON CONFLICT ("id") DO UPDATE SET "id" = EXCLUDED."id" RETURNING "inserted_at","meta","xact_id","id" [%{}, ~U[2024-12-03 00:25:32.315714Z]]
16:25:32.322 [debug] QUERY OK source="accounts" db=1.2ms
INSERT INTO "public"."accounts" (...,"inserted_at","updated_at","id") VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10) [..., ~U[2024-12-03 00:25:32.320959Z], ~U[2024-12-03 00:25:32.320959Z], "8bf14116-9ebf-4a1e-a60e-ae3cd95b0a46"]
16:25:32.323 [debug] %Postgrex.Query{ref: nil, name: "ecto_insert_merchants_0", statement: "INSERT INTO \"public\".\"merchants\" (...\"inserted_at\",\"updated_at\",\"id\") VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35)", param_oids: nil, param_formats: nil, param_types: nil, columns: nil, result_oids: nil, result_formats: nil, result_types: nil, types: nil, cache: :statement} uses unknown oid(s) 1982332forcing us to reload type information from the database. This is expected behaviour whenever you migrate your database.
16:25:32.334 [debug] QUERY ERROR source="merchants" db=10.1ms
INSERT INTO "public"."merchants" (...,"inserted_at","updated_at","id") VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35) [..., ~U[2024-12-03 00:25:32.322866Z], ~U[2024-12-03 00:25:32.322866Z], "bfa228b2-1b2e-4fdb-a2e1-ae87681d0d1f"]
16:25:32.334 [debug] QUERY OK db=0.1ms
rollback []

[maltoe]

That doesn't tell me much, unfortunately. I guess the most noticeable line in the logs is this one:

16:25:32.323 [debug] %Postgrex.Query{...} uses unknown oid(s) 1982332forcing us to reload type information from the database. This is expected behaviour whenever you migrate your database.

I think I'd try debugging this first. Are you testing migrations by any chance?

Again, it would be superb if you could try to isolate the error in a MWE, ideally something like this: #112 (comment)