DanielLeens commented on issue #10870: URL: https://github.com/apache/seatunnel/issues/10870#issuecomment-4420089755
Thanks for the detailed config and stack. I traced the current Milvus sink path before replying. The `context is null` stack is not the direct reason the job stops. In the current code, `FactoryUtil.createAndPrepareSink(...)` does a fallback probe by calling `sinkFactory.createSink(null)` first, so `MilvusSinkFactory.createSink(...)` can emit that debug-only NPE during the probe. That message is noisy, but the actual failing path in your run is later: save-mode handling checks the sink target table and returns `The sink table not exist`. The more important config point is that the Milvus sink currently reads `collection`, not `collection_name`, when it renames the target table. If `collection` is absent, `MilvusSinkFactory` falls back to the planner-provided upstream table name. In your config the key is `collection_name = "user_data"`, so the sink never switches to `user_data`, and with `schema_save_mode = ERROR_WHEN_SCHEMA_NOT_EXIST` it ends up validating the wrong target table and fails. Please try: 1. replace `collection_name = "user_data"` with `collection = "user_data"` 2. if the collection should be created automatically, switch `schema_save_mode` to `CREATE_SCHEMA_WHEN_NOT_EXIST` 3. keep the follow-up logs in English if possible, so more community members can help quickly This thread is still useful because the current Milvus sink docs/options are not clear enough here, and the fallback-probe stack is misleading. If it still reproduces after changing `collection`, please update the thread with the new log and we can continue checking. -- 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]
