replication websocket bug with composite primary key

[sir-script]

Hello everyone,

I am encountering different behaviors when streaming the replication.
In the first case (simple primary key), the user who modifies the document receives a subscribe event.
In the second case, where a composite primary key is used, the user who modifies the document does not receive a subscribe event. All other users/tabs receive the event.
Couldn't find the exact source code lines where the difference occurs while debugging.
The logic behind both cases is the same. I have checked this thoroughly and am quite sure that it is due to the primary key.
Does anyone have any idea or hint on what could be causing this?

Pseudo Code:

const replicationState = replicateGraphQL();
...
replication.received$.subscribe(() =>
  console.log('fired'),
);

Case 1:

servicePlan (primary key with a single field)

export const servicePlanSchema = {
  version: 5,
  primaryKey: 'sp_id',
  type: 'object',
  properties: {
    sp_id: {
      type: 'string',
      maxLength: 20,
    },
    description: {
      type: 'string',
    },
    resort_id: {
      type: 'string',
    },
    status_id: {
      type: 'integer',
    },
    owner_id: {
      type: 'integer',
    },
    ts_completed: {
      type: 'string',
    },
    ts_assigned: {
      type: 'string',
    },
    ts_updated: {
      type: 'string',
    },
    sort_id: {
      type: 'integer',
    },
    ts_inserted: {
      type: 'string',
    },
  },
  required: ['sp_id', 'resort_id', 'ts_updated', 'ts_inserted', 'sort_id'],
};

Server Response:

{
  "id": "c98447b0-78c9-4ebb-9c0c-d5558c2c98c0",
  "type": "next",
  "payload": {
    "data": {
      "streamServicePlan": {
        "checkpoint": {
          "sp_id": "CHECKLIST_XXX_AM",
          "ts_updated": "2024-06-24T11:53:32.194Z",
          "sort_id": 64
        },
        "documents": [
          {
            "deleted": false,
            "sp_id": "CHECKLIST_XXX_AM",
            "description": "test plan",
            "resort_id": "8bbf66d8-d894-47df-a12e-c00f4c1f0e60",
            "status_id": 0,
            "owner_id": 15,
            "ts_assigned": "2024-06-24T11:53:32.194Z",
            "ts_completed": null,
            "ts_updated": "2024-06-24T11:53:32.194Z",
            "ts_inserted": "2024-05-15T13:52:57.130Z",
            "sort_id": 64
          }
        ]
      }
    }
  }
}

Result: Subscribe event for the user who changed the document.

Case 2:

serviceObject (composite primary key)

export const serviceObjectSchema = {
  version: 3,
  primaryKey: {
    key: 'id',
    fields: ['sp_id', 'so_id'],
    separator: '|',
  },
  type: 'object',
  properties: {
    id: {
      type: 'string',
      maxLength: 40,
    },
    sp_id: {
      type: 'string',
    },
    so_id: {
      type: 'string',
    },
    name: {
      type: 'string',
    },
    description: {
      type: 'string',
    },
    type_id: {
      type: 'string',
    },
    type_name: {
      type: 'string',
    },
    master_so_id: {
      type: 'string',
    },
    status_id: {
      type: 'integer',
    },
    serial_number: {
      type: 'string',
    },
    latitude: {
      type: 'float',
    },
    longitude: {
      type: 'float',
    },
    track_name: {
      type: 'string',
    },
    position_number: {
      type: 'string',
    },
    machine_room_name: {
      type: 'string',
    },
    img_dev: {
      type: 'string',
    },
    img_mnt: {
      type: 'string',
    },
    ts_completed: {
      type: 'string',
    },
    ts_updated: {
      type: 'string',
    },
    ts_inserted: {
      type: 'string',
    },
    sort_id: {
      type: 'integer',
    },
  },
  required: [
    'sp_id',
    'so_id',
    'name',
    'ts_updated',
    'sort_id',
    'ts_inserted',
    'description',
    'master_so_id',
  ],
};

Server Response:

{
  "id": "02a021b5-c780-40f6-98ac-95189e69aaee",
  "type": "next",
  "payload": {
    "data": {
      "streamServiceObject": {
        "checkpoint": {
          "sp_id": "CHECKLIST_XXX_AM",
          "so_id": "SO-00000012-XX",
          "ts_updated": "2024-06-24T11:58:56.890Z",
          "sort_id": 877
        },
        "documents": [
          {
            "deleted": false,
            "description": "",
            "img_dev": "GUImage_tr10",
            "img_mnt": "GUMount_mobile",
            "latitude": null,
            "longitude": null,
            "machine_room_name": null,
            "master_so_id": "SO-00000012-XX",
            "name": "GU00X",
            "position_number": "998",
            "serial_number": "123-456-67811",
            "so_id": "SO-00000012-XX",
            "sort_id": 877,
            "sp_id": "CHECKLIST_XXX_AM",
            "status_id": 1,
            "track_name": "Test track",
            "ts_completed": "2024-06-24T11:58:56.890Z",
            "ts_updated": "2024-06-24T11:58:56.890Z",
            "type_id": "FANMACHINE",
            "type_name": "TR10",
            "ts_inserted": "2024-05-15T15:47:15.103Z"
          }
        ]
      }
    }
  }
}

Result: No subscribe event for the user who changed the document.

Technical Details:

Rxdb (15.12.0)
Storage: Dexie
replicateGraphQL

[pubkey]

Can you make a PR with a test case to reproduce that?
But very likely this is your server behaving different.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

[sir-script]

@pubkey Ok, thanks for the information. So, you are not aware of a similar case?
I will try to create a minimal example in the coming weeks to make it easier to reproduce.
However, this is unfortunately a bit more complex than usual because I cannot pinpoint it exactly, and Replication, Websockets and backend logic are involved.
Thanks anyway.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

[sir-script]

@pubkey Hi Daniel
I have now set up a test scenario.
It consists of a frontend repository (rxdb, react), a backend repository (nestjs, prisma), and in the backend repository, the Docker image for the database (mariadb) is also included.

Frontend Repository: https://github.com/WebWareDev/rxdb-websocket-problem
Backend Repository including Docker Image: https://github.com/WebWareDev/rxdb-websocket-problem-backend

The README files describe how to set up both repositories and how to reproduce the issue.

Best regards,
Michael

[pubkey]

Please make a PR with a test case that fails the CI.
It is not secure for me to install random projects and everything.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

[pubkey]

Closing this: #6221 (comment)