roryqi commented on issue #11709: URL: https://github.com/apache/gravitino/issues/11709#issuecomment-4732758747
Right — and the code we just read explains exactly why two servers fixes it. The whole failure depends on the proxy catalog and the IRC service sharing one relational store. In the loopback FlinkConnectorViewIcebergRestOAuth2IT setup they do, so both writes land in the same schema_meta table: IRC importSchema put → schema_id=…238, coord (test, catalog_iceberg_s3_3) proxy createSchema put (line 158, overwrite=true) → schema_id=…238, coord (iceberg_rest_view_e2e…, iceberg_rest_view_oauth2) Because PRIMARY KEY (schema_id) and the overwrite SQL is ON DUPLICATE KEY UPDATE ... metalake_id=VALUES(...), catalog_id=VALUES(...), the second write doesn't insert a new row — it rewrites the first row's coordinate. One row survives, so one of the two coordinates is gone, and the Tag resolver (which looks up by uk_cid_sn_del = (catalog_id, schema_name)) can't find the proxy coordinate → NoSuchEntityException. If you split this into two Gravitino servers with separate backend databases, the collision disappears: Server A (proxy) writes schema_id=…238 at (iceberg_rest_view_oauth2, iv_…_db) into its own DB. No one else touches that PK. Server B (the IRC) writes schema_id=…238 at (catalog_iceberg_s3_3, iv_…_db) into its DB. The Tag query runs against Server A's store, resolves (iceberg_rest_view_oauth2, iv_…_db), finds the row, and works. So yes — two servers is a correct workaround, and the fact that it works is itself confirmation of the root cause: it's the shared store + same UID PK collision, not "proxy never persists." It also tells you the e2e test's self-referential loopback (one process, one DB, a REST catalog pointing back at the same server's IRC endpoint) is what actually triggers the bug. Two caveats worth putting in the issue so maintainers don't patch the wrong layer: Splitting servers fixes the symptom but leaves the underlying fragility in place. The real smell is that the proxy forwards its own generated UID downstream as gravitino.identifier, and the IRC adopts that same UID. Any deployment that co-locates the two layers or shares a store breaks again. The robust product fix is for each layer to mint its own UID — two distinct entities in two distinct catalogs should be two schema_ids by construction. With a genuinely external (non-Gravitino) Iceberg REST catalog, there's no shared store either, so a normal user pointing a REST-backend catalog at a third-party IRC wouldn't hit this at all. That's another sign the bug is specific to the Gravitino-IRC-backed-by-Gravitino loopback rather than the REST proxy path in general. So the one-line takeaway for the issue: the problem is the shared entity store with a propagated single UID colliding on the schema_id primary key; use two servers (separate stores) to unblock the test now, and stop reusing the UID across layers for the actual fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
