Skip to content

Conversation

@adnanhemani
Copy link
Contributor

This PR adds the Events instrumentation for all APIs listed in the PolarisServiceImpl.java file, surrounding the default delegated call to the business logic APIs.


@Override
public Response createCatalog(
CreateCatalogRequest request, RealmContext realmContext, SecurityContext securityContext) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove instrumentation from #1844 for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed in next revision.

@adnanhemani adnanhemani marked this pull request as ready for review August 31, 2025 08:14
public Response listCatalogRoles(
String catalogName, RealmContext realmContext, SecurityContext securityContext) {
return delegate.listCatalogRoles(catalogName, realmContext, securityContext);
polarisEventListener.onBeforeCatalogList(new CatalogsServiceEvents.BeforeCatalogListEvent());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the right event? We are listing catalog roles, not catalogs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

catalogName, catalogRoleName, grantRequest, realmContext, securityContext);
PolarisServiceImpl.AddGrantToCatalogRoleEntityWrapper entityWrapper =
(PolarisServiceImpl.AddGrantToCatalogRoleEntityWrapper) resp.getEntity();
if (resp.getStatus() != Response.Status.BAD_REQUEST.getStatusCode()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (resp.getStatus() != Response.Status.BAD_REQUEST.getStatusCode()) {
if (resp.getStatus() == Response.Status.CREATED.getStatusCode()) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed per comment below.

return Response.ok(catalogRoles).build();
}

record AddGrantToCatalogRoleEntityWrapper(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These records have to be public, as they are potentially escaping the package (IOW, a decorator sitting outside this package would be unable to process the response returned by addGrantToCatalogRole).

These records are OK for now, but we need to include these structures in the OpenAPI spec for this service. Could you please add a TODO for that, or better yet, file an issue? WIthout proper inclusion in the OpenAPI spec, these structures become a form of "undocumented" API.

It seems the problematic endpoints are:

  • createCatalog
  • createPrincipalRole
  • createCatalogRole
  • addGrantToCatalogRole
  • revokeGrantFromCatalogRole

All of them would need to have their response schema updated in the OpenAPI spec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, this topic imo deserves a discussion thread in the ML.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense, I will start a new ML discussion regarding this. In the meantime, let me add TODOs for this and remove it for now from this PR to unblock the rest of the events.

entityWrapper.polarisPrivilege(),
entityWrapper.grantResource(),
entityWrapper.cascade()));
return resp;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, let's not include the entity in the response, since that would be a violation of the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, removing as per above comment.

new PrincipalRoleEntity(adminService.createPrincipalRole(entity)).asPrincipalRole();
LOGGER.info("Created new principalRole {}", newPrincipalRole);
return Response.status(Response.Status.CREATED).build();
return Response.status(Response.Status.CREATED).entity(newPrincipalRole).build();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: we could standardize the usage of toResponse for all endpoints.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not opposed to this, but let's do this in a different PR :)

import org.apache.polaris.core.entity.PolarisPrivilege;

public class CatalogsServiceEvents {
public record BeforeCatalogCreatedEvent(String catalogName) implements PolarisEvent {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: still some naming inconsistencies: most events use a verb in the infinitive form (BeforeCatalogListEvent) but some use the past participle (BeforeCatalogCreatedEvent).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed!

* @param privilege the privilege granted
* @param grantResource the grant resource
*/
public record AfterAddGrantToCatalogRoleEvent(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, if we eventually modify the OpenAPI spec, I think each "after" event should take a response object that mirrors the "before" event and its request object. E.g.:

record BeforeAddGrantToCatalogRoleEvent(String, String, AddGrantRequest)
record  AfterAddGrantToCatalogRoleEvent(String, String, AddGrantResponse)

{
PolarisPrivilege privilege =
PolarisPrivilege.valueOf(viewGrant.getPrivilege().toString());
privilege = PolarisPrivilege.valueOf(viewGrant.getPrivilege().toString());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a requirement, but is a helpful refactor that will help in the future if/when we change the public API.

Copy link
Contributor

@flyrain flyrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @adnanhemani for the PR. LGTM overall. Do we have tests for added events(catalog, principal, principal role)?

Comment on lines 168 to 164
return Response.status(successStatus).build();
Response.ResponseBuilder responseBuilder = Response.status(successStatus);
return responseBuilder.build();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change seems unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, this is a hangover from some other code I removed. Reverted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look reverted yet 🤔

Copy link
Contributor Author

@adnanhemani adnanhemani Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I don't know what happened and why it didn't pick up. Thanks for rechecking!

Made the changes now (and have verified)!

@adnanhemani
Copy link
Contributor Author

@flyrain - I haven't added the tests yet, but will add it in a follow up PR. I didn't want to saddle this PR with the extra LOCs for something that's quite straightforward and requires much closer attention to the details of the events themselves.

adutra
adutra previously approved these changes Sep 19, 2025
@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Sep 19, 2025
Copy link
Contributor

@flyrain flyrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 Thanks @adnanhemani !

@flyrain flyrain merged commit 553cb06 into apache:main Sep 19, 2025
14 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Sep 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants