dimas-b commented on code in PR #1817:
URL: https://github.com/apache/polaris/pull/1817#discussion_r2130614922
##########
quarkus/service/src/main/java/org/apache/polaris/service/quarkus/task/QuarkusTaskExecutorImpl.java:
##########
@@ -49,9 +52,11 @@ public QuarkusTaskExecutorImpl(
MetaStoreManagerFactory metaStoreManagerFactory,
TaskFileIOSupplier fileIOSupplier,
Tracer tracer,
- PolarisEventListener polarisEventListener) {
+ PolarisEventListener polarisEventListener,
Review Comment:
This is covered by existing tests that produce tasks.
It works like this:
1. Quarkus create a new request context when `handleTask` is called
2. The code below this like puts the `RealmContext` for the tasks into
`polarisRequestContext`
3. The Quarkus proxy for `polarisRequestContext` redirects this "set" call
to the instance in the current request context
4. When something needs a `RealmContext` during the execution of a task,
Quarkus invokes `QuarkusProducers.realmContext(PolarisRequestContext context)`
and gives it the same `PolarisRequestContext` instance that was used in step 3.
For HTTP requests step 1 is the start of the request at the REST API layer,
in which case the `RealmContext` is derived from HTTP headers by a filter.
This whole workflow is very similar to how it worked before, but we use a
custom "holder" object instead of `ContainerRequestContext`, which allows us to
support non-HTTP requests (i.e. async tasks).
--
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: issues-unsubscr...@polaris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
