feat(java): add enqueue interception#350
Conversation
Taskito.intercept(...) runs an Interceptor over each enqueue before serialization, returning Pass / Convert(payload) / Redirect(task,payload) / Reject(reason). Convert pairs with proxies; Reject throws InterceptionException. Explicit transform over the typed payload.
Convert, redirect, and reject.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR adds a producer-side interception mechanism to Taskito. New ChangesProducer-side enqueue interception
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Producer
participant DefaultTaskito
participant Interceptor
participant Middleware
participant Backend
Producer->>DefaultTaskito: enqueue(taskName, payload)
DefaultTaskito->>Interceptor: intercept(taskName, payload)
alt Reject
Interceptor-->>DefaultTaskito: Interception.Reject(reason)
DefaultTaskito-->>Producer: throw InterceptionException
else Redirect
Interceptor-->>DefaultTaskito: Interception.Redirect(taskName, payload)
DefaultTaskito->>DefaultTaskito: rewrite taskName/payload
else Convert
Interceptor-->>DefaultTaskito: Interception.Convert(payload)
DefaultTaskito->>DefaultTaskito: rewrite payload
end
DefaultTaskito->>Middleware: onEnqueue(EnqueueContext)
Middleware-->>DefaultTaskito: possibly mutated payload
DefaultTaskito->>Backend: submit gated/encoded payload
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@sdks/java/src/main/java/org/byteveda/taskito/DefaultTaskito.java`:
- Around line 154-173: `enqueueMany()` / `enqueueAll()` are still bypassing the
interception pipeline used by `dispatchEnqueue()`. Update the batch enqueue flow
in `DefaultTaskito` so each item goes through the same `Interceptor` and
`Middleware` handling as single enqueues, or explicitly disallow/document
interception for batch APIs; ensure `Reject`, `Convert`, and `Redirect` are
applied consistently before serialization and submission.
- Around line 156-164: Reject null interceptor results explicitly in
DefaultTaskito’s interceptor loop: the intercept(...) call currently falls
through when it returns null, which hides interceptor bugs and lets enqueue
continue unexpectedly. Update the logic around the Interceptor.intercept,
Interception.Reject/Redirect/Convert handling to check for a null outcome
immediately after the call and fail fast with a clear exception before any
branch processing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e4208e01-5056-4553-a870-282793b92ce5
📒 Files selected for processing (7)
sdks/java/src/main/java/org/byteveda/taskito/DefaultTaskito.javasdks/java/src/main/java/org/byteveda/taskito/Taskito.javasdks/java/src/main/java/org/byteveda/taskito/errors/InterceptionException.javasdks/java/src/main/java/org/byteveda/taskito/interception/Interception.javasdks/java/src/main/java/org/byteveda/taskito/interception/Interceptor.javasdks/java/src/main/java/org/byteveda/taskito/interception/package-info.javasdks/java/src/test/java/org/byteveda/taskito/InterceptionTest.java
What
Adds
org.byteveda.taskito.interception— a producer-side hook that inspects each enqueue before serialization and decides its fate, using a sealed strategy type.Interceptor(@FunctionalInterface) —intercept(taskName, payload)returns anInterception.Interception(sealed interface + pattern-matchingswitch):Pass— enqueue unchanged.Convert(payload)— replace the payload (e.g. with a proxy reference).Redirect(taskName, payload)— enqueue a different task instead.Reject(reason)— block the enqueue (InterceptionException).DefaultTaskito.dispatchEnqueue, ordered interceptors →onEnqueuemiddleware → predicate gate, so a redirect/convert is seen by middleware and the final gate.Taskito.intercept(interceptor)registers one (CopyOnWriteArrayList).Pairs with proxies (#349): an interceptor can
Converta non-serializable arg into a signedProxyRef. No hard dependency — interception stays decoupled.Test
InterceptionTest— each strategy (pass/convert/redirect/reject) plus ordering: an interceptor's rewrite is visible toonEnqueuemiddleware and the gate../gradlew buildgreen (JDK 17 build leg + 21/25 test legs).Summary by CodeRabbit
New Features
Tests