db apply --force now fails with 409 on a stale FK from a long-removed relationship (surfaced after #52's fix)

[Katomil]

Summary

After the fix for #52 (bare 500 on db apply's real-commit step), rayfin up db apply --force now returns a specific error instead of the old opaque one — but the error points at a foreign key that no longer exists anywhere in the live database, and the suggested remediation isn't actionable.

Environment

• CLI version: 1.33.2
• Deployment target: Fabric Apps (managed, MSSQL)
• Item has real multi-day deploy history (first deployed 2026-07-22, multiple db apply cycles since — same item referenced in up db apply: 500 Internal Server Error on every existing/pre-deployed item — new deploys succeed #52)

Repro

1. Have an entity with a @one(() => Target) relationship field, generating an FK column/constraint.
2. Refactor that field to a plain scalar (a legitimate schema change — in our case, @one(() => Product) became a denormalized @text() part-number field).
3. rayfin up db apply (no force) — fails cleanly with an unrelated destructive-change 400 guard on other pending drops. Expected.
4. rayfin up db apply --force.

Expected

Migration reconciles current entity state against actual live DB state, and applies cleanly (or fails referencing objects that actually exist).

Actual

❌ Failed to apply configuration to remote endpoint
   DAB server responded with error: 409 Conflict
   Details: The migration expected a database object that no longer exists — the database may have been changed outside Rayfin. Database reported: "'FK_DqExceptionProducts_product_id' is not a constraint.
Could not drop constraint. See previous errors.".
   RootActivityId: b0fc839e-6afc-4eb7-9e9f-1e6bcf08b0f0

Queried the live warehouse directly (sys.foreign_keys, sys.columns): no product_id column exists on the table, no FK_DqExceptionProducts_product_id constraint exists under any name — only FK_DqExceptionProducts_rule_id is real. The error's own suggested fix ("Restore the object, then re-apply") isn't actionable: there's no product_id column left in the current entity model to restore a matching FK to.

This looks like Rayfin's server-side tracked deployment/migration history for this item still references a relationship removed from the entity definitions a while ago, and reconciliation assumes that object still exists rather than diffing against the DB's actual current state.

Additional context

• Confirmed no partial commit: re-ran non-force db apply immediately after, got the same baseline 400 as before the force attempt — DB left consistent.
• Filing separately from up db apply: 500 Internal Server Error on every existing/pre-deployed item — new deploys succeed #52 rather than reopening it: up db apply: 500 Internal Server Error on every existing/pre-deployed item — new deploys succeed #52's signature was a bare, undiagnosable 500 on every attempt regardless of schema content; this is a specific, correctly-surfaced 409 pointing at genuinely stale tracked state — a different failure mode.

[lingxiao-microsoft]

Hi Katomil,

I followed your repro steps, and I was not able to fully reproduce the issue you described.

A couple of things I'd like to add here

1. If you modify the DB outside of Rayfin, Rayfin currently does not have the capability to track them.
   e.g. running T-SQL directly against the SQL DB for removing a column, Rayfin will still look for that column as it tracks what's applied via itself only and will not verify against your current live DB status.
   That means, if you have dropped the constraint FK_DqExceptionProducts_product_id manually outside of Rayfin, you will run into the error above that Rayfin still tries to delete a FK that no longer existed and fail your operation. Did you or anyone from your team happen to drop that constraint manually?

2. We have a plan to support reconciling the history tracked by Rayfin with the live DB status that will come later which will likely address your issue as such. But for now, our suggestion is not doing any manual action against the live DB to avoid getting into the cases like yours.

3. FK_DqExceptionProducts_product_id is referring to the product's id column, not product_id column.