secretflow
secretpad界面显示项目状态不一致
采用all-in-one部署，secretpad版本是secretpad:0.12.0b0
你用的pad是secretpad:0.12.0b0，你用的allinone版本是1.11的吗
参考对比下这个版本对应信息。
https://github.com/secretflow/secretpad
如果版本是1.11的，部署流程是按照官网部署的吗 有没有二次开发的动作？ https://www.secretflow.org.cn/zh-CN/docs/secretpad-all-in-one/v1.11.0b1/deployment_package
docker的版本的是多少？
采用all-in-one部署，secretpad版本是secretpad:0.12.0b0
你用的pad是secretpad:0.12.0b0，你用的allinone版本是1.11的吗 参考对比下这个版本对应信息。 https://github.com/secretflow/secretpad
如果版本是1.11的，部署流程是按照官网部署的吗 有没有二次开发的动作？ https://www.secretflow.org.cn/zh-CN/docs/secretpad-all-in-one/v1.11.0b1/deployment_package
docker的版本的是多少？
这是版本，没有二次开发
1.项目已经同意了，但是在“我的项目”菜单里显示“待同意”，如下：
2.工作台界面显示“已同意”，如下：
两个地方显示信息互相矛盾
看你创建了三个项目，前面两个创建项目正常，第三个项目跟前面两个项目创建有无其他操作区别？或者动作？
1.项目已经同意了，但是在“我的项目”菜单里显示“待同意”，如下：
看你创建了三个项目，前面两个创建项目正常，第三个项目跟前面两个项目创建有无其他操作区别？或者动作？
没有区别，这是偶现的问题，您看日志能发现问题吗
1.项目已经同意了，但是在“我的项目”菜单里显示“待同意”，如下：
看你创建了三个项目，前面两个创建项目正常，第三个项目跟前面两个项目创建有无其他操作区别？或者动作？
没有区别，这是偶现的问题，您看日志能发现问题吗
日志里面 有提示
2025-07-09 14:28:47 [289694fe-1dfc-42ab-ba0e-6b1c21080e31] [http-nio-8080-exec-2] ERROR o.s.s.w.e.SecretpadExceptionHandler - find SecretpadException error: NODE_CREATE_ERROR, message: dsc1-secretpad node create fail in kuscia :domains.kuscia.secretflow "dsc1-secretpad" already exists
这个报错提示已经有存在的的pad节点了。
方便的话再提供下，pad的data-sync.log和双方的kusica log
1.项目已经同意了，但是在“我的项目”菜单里显示“待同意”，如下：
看你创建了三个项目，前面两个创建项目正常，第三个项目跟前面两个项目创建有无其他操作区别？或者动作？
没有区别，这是偶现的问题，您看日志能发现问题吗
日志里面 有提示 2025-07-09 14:28:47 [289694fe-1dfc-42ab-ba0e-6b1c21080e31] [http-nio-8080-exec-2] ERROR o.s.s.w.e.SecretpadExceptionHandler - find SecretpadException error: NODE_CREATE_ERROR, message: dsc1-secretpad node create fail in kuscia :domains.kuscia.secretflow "dsc1-secretpad" already exists
这个报错提示已经有存在的的pad节点了。
方便的话再提供下，pad的data-sync.log和双方的kusica log
dsc2-secretpad的日志（它的secretpad.log以及error.log已经提供）:
dsc1-secretpad我找一下，稍后提供
1.项目已经同意了，但是在“我的项目”菜单里显示“待同意”，如下：
看你创建了三个项目，前面两个创建项目正常，第三个项目跟前面两个项目创建有无其他操作区别？或者动作？
没有区别，这是偶现的问题，您看日志能发现问题吗
日志里面 有提示 2025-07-09 14:28:47 [289694fe-1dfc-42ab-ba0e-6b1c21080e31] [http-nio-8080-exec-2] ERROR o.s.s.w.e.SecretpadExceptionHandler - find SecretpadException error: NODE_CREATE_ERROR, message: dsc1-secretpad node create fail in kuscia :domains.kuscia.secretflow "dsc1-secretpad" already exists
这个报错提示已经有存在的的pad节点了。
方便的话再提供下，pad的data-sync.log和双方的kusica log
上述日志均已提供
感谢你的问题发现，这个问题是产品的一个概率bug，测试团队已经发现问题并且在内部跟踪，进行中。
初步排查结论，数据未同步的消息计划持久化保存到磁盘中，本意是对这种消息未正常发送的消息继续调用处理，目前这块逻辑处理的有问题。
感谢你的问题发现，这个问题是产品的一个概率bug，测试团队已经发现问题并且在内部跟踪，进行中。
初步排查结论，数据未同步的消息计划持久化保存到磁盘中，本意是对这种消息未正常发送的消息继续调用处理，目前这块逻辑处理的有问题。
好的，导致这一块的原因是什么呢，可能是我的什么操作导致的呢，有规避的办法吗
感谢你的问题发现，这个问题是产品的一个概率bug，测试团队已经发现问题并且在内部跟踪，进行中。 初步排查结论，数据未同步的消息计划持久化保存到磁盘中，本意是对这种消息未正常发送的消息继续调用处理，目前这块逻辑处理的有问题。
好的，导致这一块的原因是什么呢，可能是我的什么操作导致的呢，有规避的办法吗
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即可。
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
方便加一下隐语技术支持微信：secretflow8 进一步沟通下？
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
方便加一下隐语技术支持微信：secretflow8 进一步沟通下？
好的，我加过你们
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
针对这个问题： 1.先尝试找到一个稳定复现的方法，内部咨询了下，目前还没稳定复现出来。 2.这个bug是数据同步问题，需要看看对应的数据同步的源码：理清调用逻辑，才知道怎么修改。 secretpad-persistence/src/main/java/org/secretflow/secretpad/persistence/datasync/
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
针对这个问题： 1.先尝试找到一个稳定复现的方法，内部咨询了下，目前还没稳定复现出来。 2.这个bug是数据同步问题，需要看看对应的数据同步的源码：理清调用逻辑，才知道怎么修改。 secretpad-persistence/src/main/java/org/secretflow/secretpad/persistence/datasync/
发现了一点可能性： 在dsc1的data-sync.log之中，scheduled-2线程在dsc1同意项目之后，又新增了一个实体类VoteRequestDO，见日志第304行，这个实体类之中的信息是REVIEWING状态，这会不会是导致这个问题的可能原因？
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
针对这个问题： 1.先尝试找到一个稳定复现的方法，内部咨询了下，目前还没稳定复现出来。 2.这个bug是数据同步问题，需要看看对应的数据同步的源码：理清调用逻辑，才知道怎么修改。 secretpad-persistence/src/main/java/org/secretflow/secretpad/persistence/datasync/
有一种感觉是VoteInviteStatusMonitor里定时任务导致的
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
针对这个问题： 1.先尝试找到一个稳定复现的方法，内部咨询了下，目前还没稳定复现出来。 2.这个bug是数据同步问题，需要看看对应的数据同步的源码：理清调用逻辑，才知道怎么修改。 secretpad-persistence/src/main/java/org/secretflow/secretpad/persistence/datasync/
1.dsc2同意项目之后，将APPROVED状态的VoteInviteDO同步给dsc1 2.dsc1还没来得及保存dsc2同步过来的VoteInviteDO，dsc1的定时任务VoteInviteStatusMonitor就执行了 voteRequestRepository.save(voteRequestDO);又把REVIEWING状态的voteRequestDO同步给了dsc2，导致dsc2之前的状态被修改
是上述原因导致的吗
问题原因：数据同步的逻辑业务逻辑需要完善。新建项目的时候偶现发生的； 临时规避方式，可以把问题项目删除，新建一个项目即可，重新发起邀约即
好的，假如我自己修复这个问题，可以提供一个修复的思路吗
针对这个问题： 1.先尝试找到一个稳定复现的方法，内部咨询了下，目前还没稳定复现出来。 2.这个bug是数据同步问题，需要看看对应的数据同步的源码：理清调用逻辑，才知道怎么修改。 secretpad-persistence/src/main/java/org/secretflow/secretpad/persistence/datasync/
1.dsc2同意项目之后，将APPROVED状态的VoteInviteDO同步给dsc1 2.dsc1还没来得及保存dsc2同步过来的VoteInviteDO，dsc1的定时任务VoteInviteStatusMonitor就执行了 voteRequestRepository.save(voteRequestDO);又把REVIEWING状态的voteRequestDO同步给了dsc2，导致dsc2之前的状态被修改
是上述原因导致的吗
目前不能确定是什么原因。 如果你这边明确验证是这个问题，可以整理下复现，验证和修改逻辑步骤，提交一个pr，给开源社区贡献一份力。