Skip to content

Refresh assigned task's datastream list when a new dedup datastream is created - #1049

Open
mittalprince wants to merge 1 commit into
masterfrom
fix/refresh-task-datastreams-on-dedup-create
Open

Refresh assigned task's datastream list when a new dedup datastream is created#1049
mittalprince wants to merge 1 commit into
masterfrom
fix/refresh-task-datastreams-on-dedup-create

Conversation

@mittalprince

Copy link
Copy Markdown
Collaborator

Summary

When a new datastream is created that reuses the task(s) of an already-assigned datastream
(e.g. destination dedup — same taskPrefix/partitions), the task's name/identity does not
change, so the normal assignment diff (ZkAdapter#diffAssignmentNodes) never touches that
task's ZK node. As a result, every instance's cached
DatastreamTask#getDatastreams() list for that task goes stale and never picks up the new
datastream — even though Coordinator#onDatastreamUpdate() already contains correct logic
to refresh it. That refresh path is simply never triggered for this scenario.

Coordinator already has a working broadcast mechanism
(Coordinator#broadcastDatastreamUpdate -> ZkAdapter#touchAllInstanceAssignments) that
touches every live instance's /assignments node, firing the existing
onDatastreamUpdate() refresh on all instances. Today it's only invoked from the
datastream-update / pause-partitions REST paths. This change also invokes it from
Coordinator#handleDatastreamAddOrDelete() whenever any datastream transitions
INITIALIZING -> READY, so newly created datastreams (including dedup datastreams that
reuse an existing task) also trigger the refresh.

This is a small, low-risk change: it reuses an existing, already-in-production broadcast
mechanism from one additional trigger point rather than introducing new machinery or
touching core assignment-diffing logic.

Testing Done

Added TestCoordinator#testTaskDatastreamsRefreshedAfterDedupeReusesExistingTask:
creates a datastream, waits for its task assignment, then creates a second datastream that
dedupes into the same destination/task, and asserts the reused task's getDatastreams()
list is refreshed to include both streams.

Verified the test reproduces the bug: reverting only the Coordinator.java change causes
the new test to fail with the exact reported symptom (task's datastreams list still only
contains the original stream after the dedup stream becomes READY). Restoring the fix
makes the test pass.

return;
}

boolean anyDatastreamReady = false;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

i think anyNewDatastreamReady is a better name as initializing state only exists for new streams

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Good catch, thanks! While digging into a CI failure this surfaced, I actually went a step further: the broadcast condition itself was too broad (it fired on every new datastream, not just dedup ones), adding unnecessary onAssignmentChange() churn. I've replaced the anyDatastreamReady flag with anyDatastreamJoinedExistingTask, set true only when a newly-READY datastream's effective TASK_PREFIX matches an already-established datastream's — i.e. only for genuine dedup/reuse cases. Better name and a narrower/more correct condition. Pushed in the latest commit.

@kanishkjaiswal2015 kanishkjaiswal2015 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

a nit comment but LGTM overall

@mittalprince
mittalprince force-pushed the fix/refresh-task-datastreams-on-dedup-create branch from 55bac32 to 18680e2 Compare August 19, 2026 04:39
… an existing task

When a new datastream dedupes into the task(s) of an already-established
datastream (same effective TASK_PREFIX), the assignment (task names) does
not change, so the normal assignment diff/rebalance path never touches the
affected task's ZK node and the task's cached datastreams list on every
instance goes stale.
Narrow the fix to only broadcast a datastream update (which triggers every
instance to refresh its locally-assigned tasks' datastreams lists) when a
newly-READY datastream actually joins an existing task group, rather than
on every datastream creation. This avoids extra onAssignmentChange() churn
for the common case of a brand-new datastream getting a brand-new task.
Also updates TestCoordinator to reflect that a task's representative
datastream can now correctly be any datastream in its dedup group.
Addresses review feedback from kanishkjaiswal2015.
@mittalprince
mittalprince force-pushed the fix/refresh-task-datastreams-on-dedup-create branch from 18680e2 to ecfddec Compare August 19, 2026 05:01
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