SEZ9 commented on issue #9192:
URL: https://github.com/apache/seatunnel/issues/9192#issuecomment-5381239801
Thanks @goutamadwant for tracing this on the current dev branch — that's
helpful. Knowing that the current path resolves `z_${table_name}` per
discovered source table, creates one Doris sub sink per table, and runs save
mode for every sub sink narrows things down, and it matches @DanielLeens's
earlier read that this looks like a multi-table / save-mode gap rather than a
plain Doris 3.0 compatibility issue.
At this point the investigation is blocked on the startup evidence that both
of you asked for. @zaki-zhao, since you reproduced this on Doris 3.0.3, could
you please provide:
1. Whether `ms_sync.z_auth_role` already existed in Doris before the job
started, or whether SeaTunnel was expected to create it during startup.
2. The Zeta master / worker logs from job startup, specifically whether
there is any `Creating table ms_sync.z_auth_role` save-mode log line before the
first stream load request that returned `table not found`.
3. If possible, a reproducible Doris 3.0.3 environment or setup steps so we
can reproduce the failure directly.
With those we can tell whether the miss is in the initial save-mode handling
or in the runtime multi-table materialization path, and avoid changing the
shared multi-table code blindly. As noted earlier, please keep follow-ups in
English so more community members can help review.
Thanks everyone for keeping this moving — this path matters a lot for CDC +
multi-table Doris users on 3.x.
<!-- streview-comment:457 -->
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
