ERROR (81171): Resolve and Reject Operation fields are still referenced from table \"directus_operations\"

[ckahle33]

Describe the bug We are using quite a few flows, and depending on the UUIDs in different environments etc, we frequently see the error:

[10:12:32.849] ERROR (81171):
    errors: [
      {
        "message": {
          "length": 386,
          "name": "error",
          "severity": "ERROR",
          "code": "23503",
          "detail": "Key (id)=(<operation_id>) is still referenced from table \"directus_operations\".",
          "schema": "public",
          "table": "directus_operations",
          "constraint": "directus_operations_resolve_foreign",
          "file": "ri_triggers.c",
          "line": "2478",
          "routine": "ri_ReportViolation"
        },
        "extensions": {
          "code": "INTERNAL_SERVER_ERROR"
        }
      }
    ]
    response: {}

running update directus_operations set resolve = NULL, reject = NULL; will fix this error and will then write the correct operation fk value in those columns on the next npx directus-sync push.

It is possible that this is a directus bug from earlier versions where the db state can be "corrupt" in a way where old deleted operations are still being referenced from directus_operations.resolve and directus_operations.reject columns.

Thank you for taking a look at this. We rely on this tool to sync flow and schema state across environments, and it has been excellent and very useful so far.

To Reproduce Steps to reproduce the behavior:

1. Create a bunch of flows with a few operations in directus
2. Run directus-sync push -c ./directus-sync.local.config.cjs

Expected behavior In some cases directus-sync push will retry to reconcile foreign key relations, which in this case, is not happening

Versions (please complete the following information):

• Directus-Sync version: ^1.5.3
• Directus version: 10.11.0
• Directus environment: Docker (local)

[EdouardDem]

@ckahle33 It seems related to this issue : https://github.com/tractr/directus-sync/issues/58 I will add tests to reproduce this bug and fix it.

[jofmi]

I also just experienced this bug - deleting the flow in question is a temporary fix :)

[vzkn]

Same issue here