CAICAIIs opened a new issue, #1072: URL: https://github.com/apache/incubator-seata-go/issues/1072
### ✅ 验证清单 - [x] 🔍 我已经搜索过 [现有 Issues](https://github.com/apache/incubator-seata-go/issues)，确信这不是重复问题 - [x] 🛠️ 我愿意自己处理这个议题 ### 🚀 Go 版本 1.23· ### 📦 Seata-go 版本 v1.2 ### 💾 操作系统 🍎 macOS ### 📝 Bug 描述 In the current Go TCC resource manager, the following methods are still left as `panic("implement me")`: - `LockQuery(ctx, param)` - `UnregisterResource(resource)` This makes the `ResourceManager` contract incomplete for the TCC branch type. If these methods are invoked by generic framework code, resource lifecycle code, or future extension paths, the process will crash instead of returning an explicit result. I checked the latest Apache Seata Java code on the official repository default branch `2.x`: （https://github.com/apache/incubator-seata/blob/2.x/tcc/src/main/java/org/apache/seata/rm/tcc/TCCResourceManager.java and https://github.com/apache/incubator-seata/blob/2.x/rm/src/main/java/org/apache/seata/rm/AbstractResourceManager.java#L153） <img width="1390" height="418" alt="Image" src="https://github.com/user-attachments/assets/5f425cbf-2213-46ca-afa3-5974fa7bffa8"; /> - `org.apache.seata.rm.tcc.TCCResourceManager` does not override `lockQuery` or `unregisterResource` - Both methods are inherited from `org.apache.seata.rm.AbstractResourceManager` - `AbstractResourceManager#lockQuery(...)` returns `false` - `AbstractResourceManager#unregisterResource(...)` throws `NotSupportYetException` So the Java side does not provide a full TCC-specific implementation either, but it does provide explicit fallback semantics instead of panicking. ## Why this matters - A `panic` turns an “unsupported / not implemented yet” case into a runtime crash - In the current Go TCC implementation, branch registration does not provide AT-style `lockKeys`, so `LockQuery` does not have AT-style lock semantics anyway - Even if the feature is intentionally unsupported for TCC, the behavior should be explicit and non-crashing ### 🔄 重现步骤 1 ### ✅ 预期行为 1 ### ❌ 实际行为 1 ### 💡 可能的解决方案 At minimum, one of the following should be implemented: 1. Align with Java-side fallback semantics - `LockQuery` returns `false`, or returns a clear “LockQuery is not supported for TCC” error - `UnregisterResource` returns an explicit unsupported error 2. Provide a more practical Go-side lifecycle implementation - `UnregisterResource` at least removes the local cached resource safely - `LockQuery` still returns explicit unsupported semantics unless real TCC lock-query semantics are introduced later -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
