nicholasbarton-nominal opened a new issue, #4553:
URL: https://github.com/apache/polaris/issues/4553
### Describe the bug
`PUT
/api/management/v1/catalogs/{catalog}/catalog-roles/{catalogRoleName}/grants`
returns HTTP 500 when a request is submitted whose grant already exists. The
duplicate-key violation from the underlying `grant_records_pkey` constraint
leaks out of `JdbcBasePersistenceImpl.writeToGrantRecords` as a generic
`RuntimeException`. We would expect a PUT to be idempotent per HTTP semantics.
### To Reproduce
Run against a Polaris build using the `relational-jdbc` persistence backend
(e.g. a Postgres-backed deployment).
1. Create a catalog and a catalog role.
2. PUT a grant to the catalog role — e.g. `TABLE_WRITE_DATA` on the catalog:
`curl -k -XPUT
"https://localhost:8181/api/management/v1/catalogs/{catalogName}/catalog-roles/{catalogRoleName}/grants";
-H "Authorization: Bearer {$TOKEN}" -H "Content-Type: application/json" -d
'{"grant": {"type": "catalog", "privilege": "TABLE_WRITE_DATA"}}'`
3. Issue the exact same PUT a second time.
### Actual Behavior
The second PUT returns HTTP 500 with a body like:
```json
{
"error": {
"message": "Failed to write to grant records due to Failed due to 'ERROR:
duplicate key value violates unique constraint
\"grant_records_pkey\"\n Detail: Key (realm_id, securable_catalog_id,
securable_id, grantee_catalog_id, grantee_id,
privilege_code)=(<realm>, <ids...>) already exists.' (error code 0,
sql-state '23505'), after 1 attempts and 5000 milliseconds",
"type": "RuntimeException",
"code": 500
}
}
```
The grant itself remains correctly in place from the first PUT; only the
response is broken.
### Expected Behavior
The duplicate PUT should succeed idempotently — returning the same success
response as the initial create (e.g. 201 Created) with no body change, and
leaving exactly one matching grant record in the database. No RuntimeException
should propagate to the client, and the SQL constraint-violation detail should
not appear in the response body.
### Additional context
I believe that the in-memory and NoSQL persistence backends are already
idempotent.
The current grant_records table has all of the fields of grant records as
part of the primary key.
### System information
_No response_
--
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]
