[v2 Bug] info schema: `dbt_rt.invocations` never contains the current invocation

[AndreaBozzo]

Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

• I believe this is a new bug in dbt v2.x
• I have searched the existing issues and could not find a duplicate

Current Behavior

With --generate-info-schema, dbt_rt.invocations holds every invocation except the current one, while dbt_rt.run_results already contains the current one's results. In a fresh project the table is empty.

A join from run_results to invocations therefore drops the current run.

Expected Behavior

dbt_rt.invocations includes the invocation that wrote the information schema.

Steps To Reproduce

dbt_project.yml

name: repro
version: "1.0.0"
profile: repro

profiles.yml

repro:
  target: dev
  outputs:
    dev:
      type: duckdb
      path: repro.duckdb

models/m.sql

select 1 as id

for i in 1 2 3; do
  dbt build --generate-info-schema --invocation-id 00000000-0000-4000-8000-00000000000$i
done

cd target/info_schema/v1
duckdb -markdown -cmd ".read views.sql" -c "
  select r.invocation_id, i.invocation_id is not null as in_invocations
  from (select distinct invocation_id from dbt_rt.run_results) r
  left join dbt_rt.invocations i using (invocation_id)
  order by 1"

Relevant log output

|            invocation_id             | in_invocations |
|--------------------------------------|----------------|
| 00000000-0000-4000-8000-000000000001 | true           |
| 00000000-0000-4000-8000-000000000002 | true           |
| 00000000-0000-4000-8000-000000000003 | false          |

All three builds exit 0 with no warnings or errors.

Environment

• OS: Windows 11
• CPU: x86
• dbt distribution and version: dbt 2.0.6 (same on 2.0.0)

Which database adapter are you using?

duckdb

Is this a discrepancy vs. dbt 1.x?

No (no information schema in 1.x).

Additional Context

Likely cause: write order. The invocation record is written after the command returns, but the information schema is written during it:

• dbt_lib.rs#L258: do_execute_fs, which reaches execute_all_phases → write_info_schema at L2092
• dbt_lib.rs#L283: ctx.write(status), after it returns

dbt docs generate already works around the same ordering with a second ingest (L2559-L2562); the general --generate-info-schema path has none. The run_results/invocations join in db.rs#L83 is affected the same way.