feat: expand Java events to full cross-SDK taxonomy - #538
Merged
Conversation
|
Warning Review limit reached
Next review available in: 24 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 Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe Java SDK adds a typed event taxonomy and emitter, exposes queue and worker subscriptions, emits enqueue, lifecycle, workflow, and compensation events, and updates dashboard/webhook handling to use wire names with legacy alias compatibility. Tests cover dispatch, payloads, ordering, and integrations. ChangesSDK event system
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
pratyush618
force-pushed
the
feat/java-event-taxonomy
branch
from
July 24, 2026 08:36
18eb887 to
0c1edab
Compare
Collaborator
|
@CodeRabbit full review |
✅ Action performedFull review finished. |
![coderabbitai[bot]](https://cdn.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/events/EventName.java`:
- Around line 7-10: Update the EventName class Javadoc to describe the enum as
the runtime event taxonomy or available event names, rather than claiming every
value is currently emitted. Preserve the documentation about dotted cross-SDK
wire names and stable terminal-outcome ordinals, and explicitly avoid implying
that WORKER_UNHEALTHY or WORKFLOW_COMPLETED_WITH_FAILURES are emitted.
In `@sdks/java/src/main/java/org/byteveda/taskito/events/OutcomeEvent.java`:
- Line 4: Update the public constructors of OutcomeEvent to validate name before
assigning or exposing it through TaskitoEvent. Reject null and any unsupported
event names using the existing event-name validation mechanism, while preserving
valid-name behavior and ensuring invalid events cannot reach Emitter.emit.
In `@sdks/java/src/main/java/org/byteveda/taskito/worker/Worker.java`:
- Around line 493-496: Update the Worker.start flow around backend.startWorker,
bridge.bind, and the WORKER_STARTED/WORKER_ONLINE emissions so startWorker and
bridge.bind complete successfully before either lifecycle event is published.
Ensure WORKER_STARTED is not emitted when startWorker or binding fails, while
preserving the existing event order after successful startup.
In `@sdks/java/src/main/java/org/byteveda/taskito/workflows/WorkflowTracker.java`:
- Line 530: In the gate-handling flow around emit(new GateEvent(runId,
node.name)), register the gate timeout before emitting the WORKFLOW_GATE_REACHED
event. Preserve the existing timeout setup and cleanup behavior so synchronous
Worker.approveGate() calls can cancel the installed timer through forget().
🪄 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 Plus
Run ID: 9b6b9c63-7670-40c7-a3c4-6eeed08dc950
📒 Files selected for processing (33)
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/dashboard/api/OpsHandlers.javasdks/java/src/main/java/org/byteveda/taskito/dashboard/api/WebhooksHandlers.javasdks/java/src/main/java/org/byteveda/taskito/events/Emitter.javasdks/java/src/main/java/org/byteveda/taskito/events/EnqueuedEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/EventName.javasdks/java/src/main/java/org/byteveda/taskito/events/GateEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/NodeCompensationEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/OutcomeEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/PredicateEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/QueueEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/TaskitoEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/WorkerEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/WorkflowEvent.javasdks/java/src/main/java/org/byteveda/taskito/events/package-info.javasdks/java/src/main/java/org/byteveda/taskito/webhooks/Webhook.javasdks/java/src/main/java/org/byteveda/taskito/webhooks/WebhookManager.javasdks/java/src/main/java/org/byteveda/taskito/worker/Worker.javasdks/java/src/main/java/org/byteveda/taskito/worker/WorkerDispatchBridge.javasdks/java/src/main/java/org/byteveda/taskito/workflows/SagaOrchestrator.javasdks/java/src/main/java/org/byteveda/taskito/workflows/WorkflowTracker.javasdks/java/src/test/java/org/byteveda/taskito/contrib/WebhookTest.javasdks/java/src/test/java/org/byteveda/taskito/core/QueueEventsTest.javasdks/java/src/test/java/org/byteveda/taskito/dashboard/DashboardOpsTest.javasdks/java/src/test/java/org/byteveda/taskito/events/EmitterTest.javasdks/java/src/test/java/org/byteveda/taskito/events/EventNameTest.javasdks/java/src/test/java/org/byteveda/taskito/events/OutcomeEventTest.javasdks/java/src/test/java/org/byteveda/taskito/webhooks/WebhookPayloadTest.javasdks/java/src/test/java/org/byteveda/taskito/worker/WorkerTest.javasdks/java/src/test/java/org/byteveda/taskito/workflows/WorkflowGateTest.javasdks/java/src/test/java/org/byteveda/taskito/workflows/WorkflowSagaTest.javasdks/java/src/test/java/org/byteveda/taskito/workflows/WorkflowTest.java
pratyush618
approved these changes
Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Grows
EventNamefrom the 4 job-outcome constants to the 26-name cross-SDK taxonomy, keeping the existing API intact (first four constants keep their ordinals;Worker.Builder.on(EventName, Consumer<OutcomeEvent>)is unchanged).wireName();fromWire()also accepts the legacysuccess/retry/dead/cancelledaliases.fromKind()(JNI contract) is untouched.TaskitoEventinterface with typed records (EnqueuedEvent,WorkerEvent,QueueEvent,WorkflowEvent,GateEvent,NodeCompensationEvent,PredicateEvent);OutcomeEventimplements it.taskito.onEvent(EventName, Consumer<TaskitoEvent>). Worker emitters chain to the queue hub, so queue-level listeners see worker events too.job.failedfires per attempt before the retry decision; worker lifecycle events on start/online/stop/offline; enqueue, pause/resume, workflow submit/cancel/terminal/gate, and saga compensation all emit."event": "job.completed", was"success"); stored legacy subscriptions keep matching, and job-outcome bodies gainduration_ms. Non-outcome events deliver per-type snake_case bodies.Emitteris lock-free thread-safe: every event name is pre-bound to aCopyOnWriteArrayListat construction, so dispatch never races registration.WORKER_UNHEALTHY(declared, not yet emitted) andWORKFLOW_COMPLETED_WITH_FAILURES(finalizer reports completed/failed today).No JNI/Rust changes. 472 tests green, strict javadoc build green.
Part of #535.
Summary by CodeRabbit
New Features
Bug Fixes