jason810496 commented on code in PR #72043: URL: https://github.com/apache/airflow/pull/72043#discussion_r3850606096
########## go-sdk/adr/0006-mixed-lang-dag-interface.md: ########## @@ -0,0 +1,115 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + --> + +# 6. Mixed Lang Dag interface + +Date: 2026-08-24 + +## Status + +Proposed. Documents the interface already shipped via #70209 and proposes renaming `Registry.AddDag` to `AddMixedLangDag`. + +## Why + +A Mixed Lang Dag's graph is defined by a Python `@task.stub` call; a Go function supplies the task body. The call site's arguments already say what data the task needs. The Go function should receive exactly that, plus whatever the SDK itself needs to inject, without either side hand-writing XCom lookups or hard-coded upstream task IDs. + +## Example + +### Registering the Dag + +```go +dag := registry.AddMixedLangDag("etl") Review Comment: The reason is that we need a different interface for the mixed Lang Dag at the user authoring level, to avoid further confusion when we support the native Dag. We need a way to distinguish whether a Go Dag definition is a mixed Lang Dag or a native Dag; otherwise, when the DagImporter is involved, the DagModel will jump between the Python Dag with Stub Operator definition and the Go native Dag for the same DagId. The alternative I had considered is having an `is_mixed_language_dag` flag at the Dag level to separate the purpose, but IMO it would be better to have an explicit, different interface, as the MixedLangDag is really a special case. Another direction is to make `Dag` a package-level function instead of coupling it as a registry method. For example: `d1 := v1.Dag("etl") d2 := v1.MixedLangDag("cross_lang") registry.AddDags(d1, d2)` -- 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]
