callback function 'onJoinChannelSuccess' not call after joinChannel()

Describe the bug
Why onJoinChannelSuccess not call ?
_engine.registerEventHandler(_engineEventHandler);

await _rtcEngine.setClientRole(
      role: ClientRoleType.clientRoleBroadcaster,
    );
await _engine.enableVideo();
await _engine.startPreview();
await _engine.joinChannel(
    token: AgoraCnf.token,
    channelId: AgoraCnf.channel,
    uid: 0,
    options: const ChannelMediaOptions(),
);

But when I call _engine.leaveChannel(). then onLeaveChannel called.

this is the logs.
[2023-11-23 16:38:04.500] [53490] [info] [iris_rtc_engine_impl.cc:52] IrisRtcEngineImpl Initialize
[2023-11-23 16:38:04.648] [53490] [info] [iris_rtc_engine_impl.cc:94] api name RtcEngine_initialize params {"context":{"appId":"d3c***************06c","channelProfile":1}}
[2023-11-23 16:38:04.702] [53490] [info] [iris_rtc_device_manager_impl.cc:29] IrisRtcDeviceManagerImpl Initialize
[2023-11-23 16:38:04.725] [53490] [info] [iris_rtc_media_player_impl.cc:30] IrisMediaPlayerImpl Initialize
[2023-11-23 16:38:04.725] [53490] [info] [iris_rtc_spatial_audio_engine_impl.cc:205] IrisLocalSpatialAudioEngineImpl Initialize
[2023-11-23 16:38:04.725] [53490] [info] [iris_rtc_media_recorder_impl.cc:17] IrisMediaRecorderImpl Initialize
[2023-11-23 16:38:04.725] [53490] [info] [iris_rtc_music_center_impl.cc:20] IrisMusicPlayerImpl Initialize
[2023-11-23 16:38:04.725] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_initialize ret 0 result {"result":0}
[2023-11-23 16:38:04.726] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_setAppType params {"appType":4}
[2023-11-23 16:38:04.726] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_setAppType ret 0 result {"result":0}
[2023-11-23 16:38:04.734] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_registerEventHandler params {"event":140512096692672}
[2023-11-23 16:38:04.734] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_registerEventHandler ret 0 result {"result":0}
2023-11-23 16:44:40.961] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_setClientRole params {"role":1,"options":null}
[2023-11-23 16:44:40.961] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_setClientRole ret 0 result {"result":0}
[2023-11-23 16:44:40.963] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_enableVideo params {}
[2023-11-23 16:44:40.964] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_enableVideo ret 0 result {"result":0}
[2023-11-23 16:44:40.965] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_startPreview2 params {"sourceType":0}
[2023-11-23 16:44:40.965] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_startPreview2 ret 0 result {"result":0}
[2023-11-23 16:44:40.970] [53490] [info] [iris_rtc_engine_impl.cc:94] api name RtcEngine_joinChannel2 params {"token":"007e***************H8k=","channelId":"hello","uid":0,"options":{}}
[2023-11-23 16:44:41.025] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_joinChannel2 ret 0 result {"result":0}
[2023-11-23 16:44:45.816] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_leaveChannel params {"options":null}
[2023-11-23 16:44:45.830] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_leaveChannel ret 0 result {"result":0}
[2023-11-23 16:44:45.831] [53490] [info] [rtc_engine_event_handler.cc:1457] channel hello uid 0
[2023-11-23 16:44:45.832] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_stopPreview2 params {"sourceType":0}
[2023-11-23 16:44:45.833] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_stopPreview2 ret 0 result {"result":0}
flutter: [onLeaveChannel] connection: {channelId: hello, localUid: 0} stats: {duration: 4, txBytes: 0, rxBytes: 0, txAudioBytes: 0, txVideoBytes: 0, rxAudioBytes: 0, rxVideoBytes: 0, txKBitRate: 0, rxKBitRate: 0, rxAudioKBitRate: 0, txAudioKBitRate: 0, rxVideoKBitRate: 0, txVideoKBitRate: 0, lastmileDelay: 0, userCount:<PHONE_NUMBER>, cpuAppUsage: 0.0, cpuTotalUsage: 0.0, gatewayRtt: 0, memoryAppUsageRatio: 1.4750242233276367, memoryTotalUsageRatio: 77.44007110595703, memoryAppUsageInKbytes: 247464, connectTimeMs: 0, firstAudioPacketDuration: 0, firstVideoPacketDuration: 0, firstVideoKeyFramePacketDuration: 0, packetsBeforeFirstKeyFramePacket: 0, firstAudioPacketDurationAfterUnmute: 0, firstVideoPacketDurationAfterUnmute: 0, firstVideoKeyFramePacketDurationAfterUnmute: 0, firstVideoKeyFrameDecodedDurationAfterUnmute: 0, firstVideoKeyFrameRenderedDurationAfterUnmute: 0, txPacketLossRate: 0, rxPacketLossRate: 0}
[2023-11-23 16:44:45.847] [53490] [info] [iris_rtc_engine_impl.cc:96] api name RtcEngine_disableVideo params {}
[2023-11-23 16:44:45.848] [53490] [info] [iris_rtc_engine_impl.cc:112] api name RtcEngine_disableVideo ret 0 result {"result":0}

Which version of agora_rtc_engine you are using?

dependencies:
  agora_rtc_engine: ^6.2.6

on macOS platform
flutter version 3.16.0

Can you try our API examples to see if it work or not?
https://github.com/AgoraIO-Extensions/Agora-Flutter-SDK/tree/main/example/lib/examples/basic/join_channel_video

I tried to run the example of version 6.2.6 on macOS, but it failed. The error message is as follows:
DT_TOOLCHAIN_DIR cannot be used to evaluate LD_RUNPATH_SEARCH_PATHS, use TOOLCHAIN_DIR instead

Can you share the flutter doctor -v info?

❯ flutter doctor -v
[✓] Flutter (Channel stable, 3.16.0, on macOS 14.1.1 23B81 darwin-x64, locale en-CN)
    • Flutter version 3.16.0 on channel stable at /Users/xxxxxx/Env/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision db7ef5bf9f (9 days ago), 2023-11-15 11:25:44 -0800
    • Engine revision 74d16627b9
    • Dart version 3.2.0
    • DevTools version 2.28.2
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    • Android SDK at /Users/xxxxxx/Library/Android/sdk
    • Platform android-34, build-tools 33.0.1
    • ANDROID_HOME = /Users/xxxxxx/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/xxxxxx/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] IntelliJ IDEA Ultimate Edition (version 2023.2.5)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.54.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-x64     • macOS 14.1.1 23B81 darwin-x64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 119.0.6045.159

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Here is my build logs.
❯ flutter run -d macos
Launching lib/main.dart on macOS in debug mode...
2023-11-24 16:41:50.881 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.881 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.882 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.883 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.884 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.884 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.884 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.884 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.884 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.884 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
2023-11-24 16:41:50.885 xcodebuild[64850:973488] [MT] DVTAssertions: Warning in /System/Volumes/Data/SWE/Apps/DT/BuildRoots/BuildRoot11/ActiveBuildRoot/Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-22269/IDEFoundation/Provisioning/Capabilities Infrastructure/IDECapabilityQuerySelection.swift:103
Details:  createItemModels creation requirements should not create capability item model for a capability item model that already exists.
Function: createItemModels(for:itemModelSource:)
Thread:   <_NSMainThread: 0x7fdd5b709960>{number = 1, name = main}
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
error: DT_TOOLCHAIN_DIR cannot be used to evaluate LD_RUNPATH_SEARCH_PATHS, use TOOLCHAIN_DIR instead (in target 'Pods-Runner' from project 'Pods')
/Users/xxxxxx/Downloads/Agora-Flutter-SDK-6.2.6/example/macos/Pods/Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.11, but the range of supported deployment target versions is 10.13 to 14.0.99. (in target 'AgoraRtcEngine_macOS' from project 'Pods')
/Users/xxxxxx/Downloads/Agora-Flutter-SDK-6.2.6/example/macos/Pods/Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.11, but the range of supported deployment target versions is 10.13 to 14.0.99. (in target 'AgoraIrisRTC_macOS' from project 'Pods')
error: DT_TOOLCHAIN_DIR cannot be used to evaluate LD_RUNPATH_SEARCH_PATHS, use TOOLCHAIN_DIR instead (in target 'Flutter Assemble' from project 'Runner')
error: DT_TOOLCHAIN_DIR cannot be used to evaluate LIBRARY_SEARCH_PATHS, use TOOLCHAIN_DIR instead (in target 'Flutter Assemble' from project 'Runner')
warning: Run script build phase 'Run Script' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'Flutter Assemble' from project 'Runner')
error: DT_TOOLCHAIN_DIR cannot be used to evaluate LD_RUNPATH_SEARCH_PATHS, use TOOLCHAIN_DIR instead (in target 'Runner' from project 'Runner')
** BUILD FAILED **

Building macOS application...
Exception: Build process failed

For the error, please check https://github.com/flutter/flutter/issues/131527

I have resolved the issue with the example. The onJoinChannelSuccess callback function in the example executes successfully, and the uid is different each time when joined the channel. However, in my own code, the onJoinChannelSuccess does not execute after joining the channel. Upon inspecting the logs, I noticed that the uid remains 0. When leaving the channel, onLeaveChannel is executed.

Can you try setting the log level to infosetLogLevel(LogLevel.logLevelInfo), and then share the logs again? I assume there's an error with your token, maybe you can check if there is any callback of the onError.


Memory leak when Reference children are removed from a page

Reproduction demo
https://codesandbox.io/s/react-popper-v1x-issue-template-3hcp9
Steps to reproduce the problem

Replace the demo code in the repo's demo/index.js file with the code in index.js of the codesandbox's index.js file
Start the demo app and load it in Chrome
Open Chrome devtools and take a heap snapshot
Click on "Toggle Popout" in the demo page
Take another heap snapshot
In the second heap snapshot look for "Detached HTMLDivElement" with the shortest distance and find in the retainer panel that referenceNode is retaining the div element

What is the expected behavior?
referenceNode in Manager is set to null when the Reference element is removed from the page.
What went wrong?
When the Reference element is removed from the page, the ref value passed to the Manager context is retained. This creates a memory leak in situations where the reference element is regularly removed from a page.
Any other comments?

This is most easily seen in a production build of React since the dev build adds a lot of extra utilities that prevents a clear exposure of the leak.

Packages versions

Popper.js: whatever version react-popper 1.3.4 depends on
react-popper: 1.3.4

It looks like the reason this is happening is because of this line in Manager.js: https://github.com/FezVrasta/react-popper/blob/master/src/Manager.js#L35
The Reference component sets its ref attribute to null when it is unmounting, but Manager no-ops when a null value is sent.

Thanks for the report! Would you mind if I asked you to send a PR with a proposed fix?

Already working on it :)
I should have one up later this morning

@FezVrasta Got a PR up for this. LMK if you want anything changed on it.


"-" at start of stack name breaks internal DNS

Rancher Version:
v1.1.0-dev4
Docker Version:
1.11.1
OS and where are the hosts located? (cloud, bare metal, etc):
Ubuntu 14.04 hyperv virtuals
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node rancher, internal db
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
This was discovered quite on accident, and is trivial, but thought should add in case anyone else comes across it. In an effort to show stacks which are in full production status first, added a "-" (dash) char in front of the name to have them sort first.
Results:
Service discovery for the stack is broken, no service names will resolve.
After a bit of freaking out and debugging realized that SD is handled by adding search domains to the containers resolv.conf file. Having a dash at the beginning of those search domains ensures that nothing can resolve.
Expected:
Validation of stack name to prevent this user error.

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


docs: reactive config updates.

Light mode:

Dark mode:

@scarmuega @paulobressan anything else you'd like to see on this PR ? Wanted to make sure it didn't fall through the cracks

thanks @caike, nice work! sorry for the delay in the merge.


Opening multiple vscode on simple call because of the cache file.

when try to open the current directory of the project using vscode it opening the other opened projects are opening that time.

I think it's because you are connected to WSL. Let it open, and then "close remote connection".
I had multiple open too before, one window is my opened project folder, another one is the WSL project. I just close the remote connection from that opened folder, then whenever I open new vscode window or open project folder, it no longer launch double window in my case.

Im not running on WSL
it is opening this file files when I launch the code
"telemetry.machineId": "",
"openedPathsList": {
"workspaces3": [
"file:///home/user/personal/messagemanagerrestapi",
"file:///home/user/personal/usermanagement",
"file:///home/user/.config"
],
"files2": [
"file:///home/user/.config/.shutdown"
]
},
and im using ubuntu

What is your window.restoreWindows setting?

I'm having the same problem , with ubuntu.
my "window.restoreWindows": "all",
I'm not running WSL either

/duplicate https://github.com/microsoft/vscode/issues/92318


FileNotFoundException, The file  "./." does not exist

it work on my localhost, but not on live server

what should i do.?

Hi there,
Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

Thanks!


[Feature Request] Vimscript stopinsert!

The current implantation of vimscripts stopinsert is a bit lacking. When you call stopinsert it does not fire until after the updatetime has transpired. Resulting in plugins having to do work arounds to get it to function correctly. It would be great if there was a way to do stopinsert! and have it leave insert mode immediately.

Am 2015-09-16 07:54, schrieb vito-c:

The current implantation of vimscripts stopinsert is a bit lacking.
When you call stopinsert it does not fire until after the updatetime
has transpired. Resulting in plugins having to do work arounds to get
it to function correctly. It would be great if there was a way to do
stopinsert! and have it leave insert mode immediately.

Can you please provide an example, where stopinsert does not work
how you expect it?
Best,
Christian


One or two more ideas/requests ^^

Repost from the discussion section since I read you usually do not consult it !
Hey there, a little request since there already is a collection of varioux fixes and new additions ^^
Would it be possible to add a feat that would allow casting while enraged ?
By RAW it's a metamagic feat with extra bits but I'd rather have a feat for just the casting part...
Perhaps it's not that simple since there are quite a few rage features with barbarian/skald/instinctual warrior etc... (but hey, the latter would be quite something since there is no other (morale?) WIS bonus for casters !)
Completly unrelated : would it be possible to re enable the basic arcanist capstone (Magical supremacy) for either the Phantasmal mage or the Brown fur transmuter.
For one I think it's not quite overpowered since there already is a heavy usage of arcane points for other things, and on top of that it would allow both archetypes with the cumulative rules :p

Will see with rage. The capstone is too specific. I can tell you how to get that with Toybox, but it seems unnecessary to code.
Btw, I got a notification but didn't think to look in discussions :P
Also, the game does not support multiple archetypes at all, even if legal. The complexity would have been significant, so I can totally see why.

Thanks !
Well I guess I can add features from one archetype to the other (probably simpler to add BFT to Phantasmal).
Just adding powerful charge and other abilities should work I guess)
Multiple archetypes can be used with Toybox actually without any issue so far (it deactivated conflictual archetypes as should be)

Was a bit in rush because of the game update. Would you mind testing "Mad Magic"?

So I tested the feat with Instictual warrior (so Focused Rage), and could neither cast spell nor use kinetic blasts (since they are spell like).

Works now. I forgot to add a null check.

So far all good among various tests, thank you very much :)


Marcio/web-gateway

added pcx metadada
corrected links

Hi @Lekensteyn @lukevalenta @thibmeu. Please ignore my previous PR as I made a mistake and had created it from another one. This is to add PCX metadata and I've gone and corrected some links that were broken. Please see they make sense, specifically the one about Google's Project Shield. That one didn't work and I had no context about it. Thank you


[2.4] Rancher server pods crash with goroutine panic due to concurrent map read and write

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
Enable dashboard on Rancher 2.4
Result:
The rancher pods will consistently crash with goroutine panic due to concurrent map read and write. Segfaults are reported in the system logs at the time that the goroutine panic is seen.
Other details that may be helpful:
This code gets called only if the dashboard is enabled, so disabling it fixes the issue.
Environment information

Rancher version: v2.4.5

Relevant stack trace:
2020-08-07T16:44:40.526435030Z fatal error: concurrent map read and map write
2020-08-07T16:44:40.529825624Z
2020-08-07T16:44:40.529838454Z goroutine 47028 [running]:
2020-08-07T16:44:40.529842699Z runtime.throw(0x3fb5abb, 0x21)
2020-08-07T16:44:40.529846089Z 	/usr/local/go/src/runtime/panic.go:774 +0x72 fp=0xc042f13d20 sp=0xc042f13cf0 pc=0x42fb12
2020-08-07T16:44:40.529850274Z runtime.mapaccess2_faststr(0x3642e20, 0xc03b9e1470, 0xc03513f1c0, 0x1d, 0x0, 0x0)
2020-08-07T16:44:40.529853995Z 	/usr/local/go/src/runtime/map_faststr.go:116 +0x48f fp=0xc042f13d90 sp=0xc042f13d20 pc=0x41335f
2020-08-07T16:44:40.529857761Z github.com/rancher/rancher/vendor/github.com/rancher/steve/pkg/schemaserver/subscribe.(*WatchSession).watch(0xc0271a3300, 0xc00d11f4a0, 0xc01570b140, 0x0, 0x0)
2020-08-07T16:44:40.529861769Z 	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/steve/pkg/schemaserver/subscribe/watcher.go:129 +0x1e7 fp=0xc042f13ed8 sp=0xc042f13d90 pc=0x25be957
2020-08-07T16:44:40.529865555Z github.com/rancher/rancher/vendor/github.com/rancher/steve/pkg/schemaserver/subscribe.(*WatchSession).Watch.func1(0xc01570b140, 0xc0271a3300, 0xc00d11f4a0)
2020-08-07T16:44:40.529869403Z 	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/steve/pkg/schemaserver/subscribe/watcher.go:98 +0x91 fp=0xc042f13fc8 sp=0xc042f13ed8 pc=0x25bee71
2020-08-07T16:44:40.529872935Z runtime.goexit()
2020-08-07T16:44:40.529876744Z 	/usr/local/go/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc042f13fd0 sp=0xc042f13fc8 pc=0x45f7a1
2020-08-07T16:44:40.529880291Z created by github.com/rancher/rancher/vendor/github.com/rancher/steve/pkg/schemaserver/subscribe.(*WatchSession).Watch
2020-08-07T16:44:40.529883891Z 	/go/src/github.com/rancher/rancher/vendor/github.com/rancher/steve/pkg/schemaserver/subscribe/watcher.go:95 +0x6c
2020-08-07T16:44:40.529887782Z

gzrancher/rancher#11655
gzrancher/rancher#11655
gz#12649
gz#13505

See:

https://github.com/rancher/steve/blob/release/2.4/pkg/schemaserver/subscribe/watcher.go#L41
z1-11655-w....

Verified on 2.4.12-rc3 and 2.4-head - commit id: ca0c2b9f4

Able to deploy rancher.
No panics seen
Deployed an rke 1 node cluster successfully.

Verified on 2.4.12-rc3 and 2.4-head - commit id: ca0c2b9f4

Able to deploy rancher.
No panics seen
Deployed an rke 1 node cluster successfully.

Reopening for an RKE RC from release/v1.1 branch and vendoring in changes to rancher

Reopening for an RKE RC from release/v1.1 branch and vendoring in changes to rancher

On 2.4.13-rc1

Able to deploy rancher.
No panics seen
Deployed an rke  cluster successfully.
Closing this issue for now.

On 2.4.13-rc1

Able to deploy rancher.
No panics seen
Deployed an rke  cluster successfully.
Closing this issue for now.


{Bp-2592} lvgl: upgrade to release/v9.2.1

Summary
Upgrade LVGL to release v9.2.
Relates Issue: https://github.com/apache/nuttx-apps/issues/2461.
Impact
RELEASE
Testing
CI

[Experimental Bot, please feedback here]
This PR appears incomplete based on the NuttX requirements.
Here's why:

Summary Lacks Detail:  While stating the change (upgrading LVGL), the summary needs to elaborate on:

Necessity:  Why is upgrading to v9.2 important? Bug fixes? New features NuttX needs?
Functional Change:  Be specific about which parts of the codebase are affected by the LVGL upgrade.
How it Works: Provide a concise explanation of how the upgrade is implemented.

Impact Assessment: The "RELEASE" statement under Impact is too vague. Address all impact points with specifics:

New/Changed Features:  Does v9.2 introduce features NuttX will now support?
User Impact: Will users need to make changes to their applications or configurations?
Build Impact: Are there build system modifications required due to the LVGL upgrade?
Hardware Impact: Does this affect specific architectures, boards, or drivers?
Documentation: Is documentation impacted (e.g., new features to document, API changes)?
Security/Compatibility:  Analyze and state any security implications or compatibility concerns.

Testing Is Insufficient:

CI Alone is Not Enough:  While CI is valuable, you need to provide evidence of local testing.
Detailed Test Setup: Specify the exact host and target environments used for testing.
Relevant Test Logs: Include logs that demonstrate the issue before the change and the correct behavior after the change. Focus on logs relevant to LVGL.

In short, provide more context, be specific about the impact, and show concrete evidence of testing to make this PR ready for review.


Unable to get sparse point cloud with colmap with 2 images with known pose

Hi,
I'm trying to train DS-NeRF on two images whose intrinsics and extrinsics are known. I followed this link you suggested in Issue-20, but colmap point_triangulator is failing because it triangulated 0 points.
To debug, I used the fern_2view data and ran imgs2poses.py to obtain camera params and point cloud. Then I followed the known-camera-poses procedure (I removed every second line in images.txt), but it fails even for that. In other words, for the exact same camera params for which first approach worked, the second approach didn't work. So, it can't be a problem with the data, but instead it should be something that I'm doing incorrectly.
I'm new to NeRF and Colmap. Can you please help me out.
More details:
I created a new folder fern_trial and in images folder, added the two images and renamed them as image001.png and image002.png. Also created an empty sparse folder.
This works:
fern_trial$ colmap feature_extractor --database_path database.db --image_path images --ImageReader.single_camera 1
fern_trial$ colmap exhaustive_matcher --database_path database.db
fern_trial$ colmap mapper --database_path database.db --image_path images --output_path sparse --Mapper.num_threads 16 --Mapper.init_min_tri_angle 4 --Mapper.multiple_models 0 --Mapper.extract_colors 0

This does not work:
fern_trial2$ colmap feature_extractor --database_path database.db --image_path images --ImageReader.single_camera 1

I copied camera.txt and images.txt (deleted every second line) from fern_trial to this folder.
fern_trial2$ colmap exhaustive_matcher --database_path database.db
fern_trial2$ colmap point_triangulator --database_path database.db --image_path images --input_path sparse/0 --output_path sparse2 --Mapper.num_threads 16 --Mapper.init_min_tri_angle 4 --Mapper.multiple_models 0 --Mapper.extract_colors 0

I was able to get this with an additional setting  --Mapper.tri_ignore_two_view_tracks 0 for the point_triangulator


[Snyk] Upgrade @typescript-eslint/parser from 5.50.0 to 5.51.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @typescript-eslint/parser from 5.50.0 to 5.51.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 17 versions ahead of your current version.
The recommended version was released 22 days ago, on 2023-02-06.

Release notes

Package name: @typescript-eslint/parser

5.51.0 - 2023-02-065.51.0 (2023-02-06)
Bug Fixes

eslint-plugin: [sort-type-constituents] fixed behavior change (#6384) (5bf7f7f), closes #6339
eslint-plugin: do not use .at(), Node 14 does not support it (#6402) (077ed1b)

Features

eslint-plugin: [naming-convention] improve performance by removing unnecessary selectors (#6376) (3647a1c)
eslint-plugin: [no-floating-promises] error on logical expression (#6356) (f330e06)
eslint-plugin: [no-import-type-side-effects] add rule to warn against runtime side effects with verbatimModuleSyntax (#6394) (b14d3be)
eslint-plugin: [strict-boolean-expressions] add allow nullable enum to strict boolean expressions (#6096) (d4747cd)
typescript-estree: cache project glob resolution (#6367) (afae837)

5.50.1-alpha.15 - 2023-02-06

5.50.1-alpha.14 - 2023-02-05

5.50.1-alpha.13 - 2023-02-05

5.50.1-alpha.12 - 2023-02-03

5.50.1-alpha.11 - 2023-02-03

5.50.1-alpha.10 - 2023-02-02

5.50.1-alpha.9 - 2023-02-01

5.50.1-alpha.8 - 2023-02-01

5.50.1-alpha.7 - 2023-01-31

5.50.1-alpha.6 - 2023-01-31

5.50.1-alpha.5 - 2023-01-31

5.50.1-alpha.4 - 2023-01-31

5.50.1-alpha.3 - 2023-01-31

5.50.1-alpha.2 - 2023-01-31

5.50.1-alpha.1 - 2023-01-31

5.50.1-alpha.0 - 2023-01-31

5.50.0 - 2023-01-315.50.0 (2023-01-31)
Bug Fixes

ast-spec: a JSXEmptyExpression is not a possible JSXExpression (#6321) (4b27777)
eslint-plugin: [ban-ts-comment] counts graphemes instead of String.prototype.length (#5704) (09d57ce)
eslint-plugin: [prefer-optional-chain] fix ThisExpression and PrivateIdentifier errors (#6028) (85e783c)
eslint-plugin: [prefer-optional-chain] fixer produces wrong logic (#5919) (b0f6c8e), closes #1438

Features

eslint-plugin: add key-spacing rule extension for interface & type declarations (#6211) (67706e7)

    from @typescript-eslint/parser GitHub release notes

Commit messages

Package name: @typescript-eslint/parser

a9cb860 chore: publish v5.51.0
cb4d6ac test: remove now-unnecessary jest-resolver.js (#6429)
3e102fe chore(typescript-estree): remove unnecessary babel test exclude (#6427)
d4747cd feat(eslint-plugin): [strict-boolean-expressions] add allow nullable enum to strict boolean expressions (#6096)
f330e06 feat(eslint-plugin): [no-floating-promises] error on logical expression (#6356)
fc24a57 chore: update sponsors (#6417)
a948729 chore: enable one-var rule  (#6410)
b14d3be feat(eslint-plugin): [no-import-type-side-effects] add rule to warn against runtime side effects with `verbatimModuleSyntax` (#6394)
add18e7 chore: update contributors (#6406)
afae837 feat(typescript-estree): cache project glob resolution (#6367)
3647a1c feat(eslint-plugin): [naming-convention] improve performance by removing unnecessary selectors (#6376)
f366b6f chore: test on Node 14 (#6400)
5bf7f7f fix(eslint-plugin): [sort-type-constituents] fixed behavior change (#6384)
056e9f0 docs(eslint-plugin): fix key-spacing core rule name (#6395)
077ed1b fix(eslint-plugin): do not use .at(), Node 14 does not support it (#6402)
fbe811c chore: enable eqeqeq internally (#6228)
2c61bdb chore(website): consistent .mdx file naming (#6325)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
Patch coverage has no change and project coverage change: -0.39 :warning:

Comparison is base (edaa3ab) 92.36% compared to head (d75cca1) 91.98%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #185      +/-   ##
==========================================
- Coverage   92.36%   91.98%   -0.39%
==========================================
  Files           9        9
  Lines         262      262
==========================================
- Hits          242      241       -1
- Misses         20       21       +1

Impacted Files
Coverage Δ

lib/function-loader.js
88.46% <0.00%> (-3.85%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Update _polygon_to_line.py

Please make sure that:

[x] You have read CONTRIBUTING.md
[x] You Include a link to the issue this pull request is associated to.
[x] The linter has been run at the root level of the project: black .
[x] All tests are passing: python -m pytest --verbose --cov=./
[x] Your branch is up to date with master: git rebase upstream/master

Corrects https://github.com/pyturf/pyturf/issues/65.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e51fa03) 97.56% compared to head (bbaa0b8) 97.56%.
Report is 1 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master      #66   +/-   ##
=======================================
  Coverage   97.56%   97.56%
=======================================
  Files         123      123
  Lines        2878     2878
=======================================
  Hits         2808     2808
  Misses         70       70

Flag
Coverage Δ

unittests
97.56% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fixes an issue with empty lines around modifier keyword and beginning of a block

There is no way that the following code is valid for rubocop. It will either complain about the missing empty line above the access modifier (Style/EmptyLinesAroundAccessModifier) or the empty line at the beginning of a block (Style/EmptyLinesAroundBlockBody).
included do
  private

  def bar
  end
end

This example occured when using rails concerns.
This PR fixes this issue. Please let me know if I can improve my PR, I'm looking forward to contribute!

Coverage increased (+0.0%) when pulling 8b43f7271742b698b46f860625627e43da7b3689 on volkert:empty-lines-with-blocks-and-modifiers into 76501162aee4c2c766a1dcd86975598f9835c6de on bbatsov:master.

I don't know why the build on travis is failing, it doesn't seem to be related to my change. Am I missing something there?

Seems like some JRuby bug...

Coverage increased (+0.32%) when pulling 86f1e6c2773b707cdcec87b53caef40012de3b3a on volkert:empty-lines-with-blocks-and-modifiers into 7fa6456cf74d68f5d0a7074791d6d5e84274112b on bbatsov:master.

The code seems OK to me now. Just squash the two commits together and we're good to go.

Done!

Like this?

:+1: Indeed. Thanks for fixing this!


Adding timestamp to log output

It would be nice to have this feature! Especially for Windows there is no good serial monitor software available.

Hi @si-moon, thanks for reaching out! Our Serial Monitor actually already supports this!
This button toggles the timestamp when monitoring.

Does using this feature meet your needs?


Code to display and interact with PDBe 3D viewer (LiteMol) in the Tra…

…nscript and Variation portals
This is the big PR with most of all the code (some as been added to ensembl-webcode)
Associated witht the ensembl-webcode PR https://github.com/Ensembl/ensembl-webcode/pull/667
Examples:

Transcript: http://ves-hx2-76.ebi.ac.uk:5060/Homo_sapiens/Transcript/PDB?t=ENST00000304043
Variation: http://ves-hx2-76.ebi.ac.uk:5060/Homo_sapiens/Variation/PDB?v=rs699

Code looks ok. can you please add your sandbox url and also is your branch uptodate with master?

sorry just saw your sandbox url on the other PR, dont worry about the url, can you please confirm your branch is uptodate with master

Hi RIdwan,
Yes I based this PR on the latest code on the Ensembl/ensembl-webcode master branch


[5.0] [string] Fix string implementation for big endian platforms

Backport of #21077 to the 5.0 branch.
This fix is needed for the new small string optimizations to work on big endian platforms. It doesn't affect the ABI.

@swift-ci clean test

@milseman @airspeedswift please review


Rails/HasManyOrHasOneDependent with paranoia gem

Hi!
Do you have any suggestions how to use gems providing soft-delete (like paranoia) with HasManyOrHasOneDependent cop: I think it's usual to not provide dependent option to has_many when parent is soft-deletable. Is it supposed just to use rubocop:disable for offences in such cases?
RuboCop version
$ rubocop -V
0.52.0 (using Parser <IP_ADDRESS>, running on ruby 2.4.1 x86_64-darwin16)

We're in the process of moving all Rails-related functionality to a standalone library (gem) named rubocop-rails. Please, migrate this issue to its issue tracker https://github.com/rubocop-hq/rubocop-rails/issues/


[FLINK-19743] Add metric definitions in FLIP-33 and report some of them by default.

What is the purpose of the change
This patch does the following:

Moved the MetricNames from flink-runtime to flink-core and added the metrics defined in FLIP-33.
Improved the SourceReaderBase API to allow additional information to be passed from the SplitReader to RecordEmitter. So that the implementations do not have to put some common information in the records themselves.
Report some of the metrics by default.

Metrics implemented by the SourceOperator / ReaderOutput:

currentEmitEventTimeLag (at a sampling frequency of once per second)
watermarkLag

Metrics implemented in the SourceReaderBase (can be overridden by individual implementations):

numRecordsIn / numRecordsInPerSecond
sourceIdleTime

Metrics left for individual implementations to report in SplitReader / RecordEmitter :

numBytesIn / numBytesInPerSecond
currentFetchEventTime
pendingBytes
pendingRecords
numRecordsInErrors (errors in SplitReader and record emitter)

Brief change log

Moved the MetricNames from flink-runtime to flink-core and added the metrics defined in FLIP-33.
Improved the SourceReaderBase API to allow additional information to be passed from the SplitReader to RecordEmitter. So that the implementations do not have to put some common information in the records themselves.
Report some of the metrics by default.

Verifying this change
Unit tests have been added to test the metrics reporting and additional information passing between SplitReader and RecordEmitter.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (yes)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (yes)
If yes, how is the feature documented? (docs / JavaDocs)

@StephanEwen @zentol This is the patch for FLIP-33. Do you have time to take a look? Thanks!

Sorry to be late to the game here, but could you share a bit more information on what the original setup was?
Specifically, what was your checkpoint storage system that offered such bad stream read performance? Was it HDFS? OSS? S3?
Looking at this change here, it seems very big (40 files) for "just" introducing a buffer in a stream.
So I tend to be -1 on the change as it is.
Two other options to solve this:
(1) Input stream buffering is a property of the CheckpointStorage. It is created there, rather than in the state backends that have to wrap the stream.
(2) Alternatively, we can make it a contract that all FileSystem implementations return well buffered streams. Some already do this by default, wrapping them with another buffered stream adds just another layer and extra copying of bytes, costing performance.
At a first glance, I'd say let's go with option (2) if possible, otherwise option (1).
Hence the question: Which FS did you use that had such bad performing streams?

Taking a look now.
@becketqin The code currently fails with NullPointerException in some tests.

Thanks for implementing this.
At a first glance, I think moving the MetricNames to flink-core does not work too well.  The metric names don't have a meaning by themselves. They depend on the Metric Scope (think of it like a package/namespace) to build the full name. Without that, they are like a classname without package. Not unique, not instantiable, not queryable, etc. Just an incomplete fragment. They cannot be used in islolation.
That was more coherent in the original place, the runtime metrics package, next to the runtime metric groups, which define the scope and build the full name.
This looks like "premature consolidation". We could just keep the runtime metric names as they are, and have a separate class for source metric names. A bit like the config options, where the connector base also defines it's options in it's own module, rather than in a shared core class. The argument for metrics names is even stronger, because of the aforementioned issue that the names alone are incomplete.

@zentol Curious what your take is here.

The PR adds a new numBytesIn metric to the OperatorIOMetricGroup. That means all operators now show that metric. But the metric is zero for the majority of operators (all except for sources), because all other operators never receive bytes (just records).
I think that is an issue.
An idea would be investigate the following approach:

Define a SourceMetricGroup interface that extends MetricGroup and has the additional methods for pre-defined metrics (getNumRecordsIn(), ...). That would also make the SourceContext interface a bit nicer, because all metric-related methods are in the metrics group. We don't need to extend the SourceContext interface each time a new pre-defined metric gets added.

Implement a SourceMetricGroupImpl that reuses some metrics (counters / Gauges) from the OperatorIOMetricGroup (the numRecordsIn) and some metrics from the TaskIOMetricGroup (the numBytesIn metrics). That way the source's numBytesIn contribute to the tasks's numBytesIn and are also displayed in the web UI main job overview.

A thought on performance: There are some metrics that use volatile variables.
So far we always avoided that. Even "infrequently accessed" fields, like watermarks, are quite frequent in some use cases.
And a single volatile write has a very significant overhead in a high-performance pipeline. It is the number one thing we try to avoid, because it breaks the processor pipeline and puts pressure on the memory bus and processor's cache coherency mechanism. For the metrics, performance (least impact on main data paths) should have clear precedence.
For metrics, we don't need a hard "happens before" relationship or any "immediate visibility". If the visibility is some 100s of milliseconds later (which would be a lot), it is no issue for the metrics at all, which are periodically reported every few seconds.
The case where the JIT inlines the variable and eliminates cross-thread visibility entirely is AFAIK not realistic here. And if we ever find that the metric gets not reported, we can still use an occasional volatile write (like we do occasional volatile exception checks, every 1000 records, in the network stack).

A thought on performance: There are some metrics that use volatile variables.
So far we always avoided that. Even "infrequently accessed" fields, like watermarks, are quite frequent in some use cases.
And a single volatile write has a very significant overhead in a high-performance pipeline. It is the number one thing we try to avoid, because it breaks the processor pipeline and puts pressure on the memory bus and processor's cache coherency mechanism. For the metrics, performance (least impact on main data paths) should have clear precedence.
For metrics, we don't need a hard "happens before" relationship or any "immediate visibility". If the visibility is some 100s of milliseconds later (which would be a lot), it is no issue for the metrics at all, which are periodically reported every few seconds.
The case where the JIT inlines the variable and eliminates cross-thread visibility entirely is AFAIK not realistic here. And if we ever find that the metric gets not reported, we can still use an occasional volatile write (like we do occasional volatile exception checks, every 1000 records, in the network stack).

Thanks for the comments and suggestions. I was actually struggling on this a little bit. The current implementation is based on the following assumptions:

The volatile read is usually as cheap as a normal variable read unless there is write contention. Modern CPUs can achieve a cheap read if there isn't a contention on the shared variable. The CPU cache line usually can cache the shared variable and just read from it. The reads only go to main memory if the value has been updated by another core, in that case the reading CPU's cache line is invalidated.
In the current implementation, the main thread performs a read on a volatile variable of shouldUpdateCurrentEventTimeLag for every record. The shouldUpdateCurrentEventTimeLag is set to true by a separate thread every second. If the main thread sees the value becomes true, it will update the volatile variable of currentEmitEventTimeLag with System.currentTimeMillis() - timestamp. So this is a volatile variable write and potentially a system call that the main thread performs once per second.
The watermark update is infrequent. From your comment this assumption seems to optimistic. So we can probably also update the currentWatermark once per second.

Another part that took me some time to think about is whether we should use number-of-record-based interval v.s. time-based interval for metric reporting. In cases when there is a large throughput, these two approaches probably won't make any difference. But in case of low throughput, time-based-interval seems preferable. Imagine we emit record every 1000 records, but there is a low throughput stream that only processes one record every 5 seconds. In order to see the metrics get updated we need to wait for over an hour, which seems bad.
I am curious do we have some experience that invalidates these assumptions?

@StephanEwen Thanks for the comment. I have updated the patch. Would you help take a look?
I have also left some thoughts regarding the performance impact. Please let me know if you still have concerns.
Just want to add to the performance discussion. The first version of implementation I had has a DynamicMetricSampler class which does the following:

Take a target metric reporting overhead in percentage, for example, 0.01%.
Measure the absolute time it takes to report a metric, e.g. 1000 ns.
Based on the overhead and throughput, it calculates the metric sampling interval. In the above case, if the throughput is 1000 records per second, each record takes 1 ms (1,000,000 ns) to process. If the overhead is 0.01%, the budget for metric reporting is 100 ns per record. Given that each metric reporting takes 1000 ns, the sampling interval should be every 10 records.
The metric sampling interval is adjusted periodically to reflect the latest throughput.

The above logic allows a quantifiable bounded performance impact on the throughput. But I removed because In most cases, periodical reporting is good enough, e.g. reporting metrics every second. So we can avoid some complexity. If you think this approach helps, we can also bring that in.

On Volatile Reads and Performance Considerations
I think volatile read assumption is completely correct. There is a common interpretation that this just means "load variable from memory if modified by another thread", meaning it's for free if no other thread touches it. But volatile reads in Java insert a "load barrier" for the processor - it affect all variables and memory after that barrier, to guarantee the happens-before relationship between everything before/after that volatile read. In hardware (x86), a load barrier means draining the processor's load buffer completely before continuing, which may (and frequently will) stall the processor pipeline.
As a concrete example in Flink: If you look at the current mailbox runtime in the StreamTask, it does in fact a lot more work before processing a record than the previous "run loop", but is still faster, purely because it has less volatile variable access.
Here are two good references:

https://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html
https://www.infoq.com/articles/memory_barriers_jvm_concurrency/

The conclusion here is to use volatile only where you want to establish load/store barriers. Typically at the end of a block of work.
In Flink this means the following:

We have the load/store barriers already once after every record is processed, by the mailbox. That is enough to make sure changes by the processing thread during one record's processing are made visible to other threads before the next record is processed.
We don't need a specific additional happens-before relationship around values for metrics, so the metrics do not need an additional volatile access.

There is now also an additional static thread to work with that variable, which is one more utility thread. There have been quite a few of those recently added to Flink, and I think we should start to be careful about adding those. One thread alone doesn't hurt, but it adds up over time. Every thread adds memory footprint overhead (more than 1MB, again sounds not like much, but doing this 10s of times makes a difference) and increases overhead through context switches (having 10s of additional threads that jump in every second will eventually be measurable). So threads should be added is necessary, but not if there is another equally good solution.
I think we really should go the "keep it simple" approach here. No volatile on the metric path, no extra threads for "black magic". Simplest possible solution, as predictability as possible. I believe it will actually work well, the remaining metric code follows that principle and I am not aware of any problem.
If we actually discover problems, we can still look at adding a complex magic solution. But I am very hesitant to add that complexity now, without really knowing there is a problems that warrants such a solution. Complexity should not come before the problem.
Event-time Lag Gauge
We can grab the watermark "for free" this way:

We don't have to eagerly compute the lag. The best point to compute it is directly when the metric is probed, in the Gauge.getValue() method. The we compute it exactly as often as it is needed.
The computation then happens in the metric reporter or the single metric thread that periodically gets all metric values to report them.
All watermarks leave the source through the WatermarkOutput defined here: https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/operators/source/ProgressiveTimestampsAndWatermarks.java#L101
The field WatermarkToDataOutput.maxWatermarkSoFar already has the value we need. So the getValue() method could simply to Math.max(0L, System.currentTimeMillis() - output.getMaxWatermarkSoFar()).

Not using a volatile field here would still guarantee visibility (through the barriers in the mailbox), visibility might just be a few micoseconds late, because we don't flush and wait for the store buffer in the processor.

@StephanEwen Thanks for the detail explanation. I updated the patch to address your comments and removed the controversial part. Now the patch only contains two commits:

Add metric definitions of Source.

Expose the Source metrics via SourceMetricGroup and SourceReaderContext.
Let SourceOperator report the WatermarkLag.

Report numRecordsIn, numRecordsInPerSecond and SourceIdleTime in SourceReaderBase.

Would you help take another look? Thanks.

I don't particularly like the current way of passing in the numBytesInCounter from the TaskMetricGroup. It is probably cleaner to replace that with the SumCounter.

It is actually even simpler. The numBytesInCounter in the TaskMetricGroup can be accessed all the way up from the SourceOperator.

@StephanEwen Thanks a lot for the review. I have addressed most of them.
Regarding the questions about sourceIdleTime.

Can we deactivate this during batch processing? It seems less valuable there, and we have been very performance conscious for batch workloads.
It seems that the cost of skipping updating this metric could be the same or even more than just updating the idle time which is a local variable, because the skipping code would likely result in an if-else branch that involves reading from a variable and branch prediction logic in the CPU.

One change I made in the last update is putting the sourceIdleTime = -1L right after we got a non-null recordsWithSplitIds. So the sourceIdleTime will only be updated once per batch, instead of once per record. I think this should have little performance impact on the current code, if any.

The metric measures the time since last record. That metric fluctuates heavily, resets to zero multiple times per second. A lot of the actual information (how much idleness there was in total) will be lost by the time the metric is sampled. The mailbox idleness tries to measure the average idleness fraction of the total processing time. Is that something that would be good for this metric as well, or should it stay as it is?
I think the idleness fraction is particularly useful to measure the workload of a thread. In the source case, users usually care more about for how long there is no data processed from a source. I don't think this metric is critical, but could help clarify the latency issues in some cases, especially when some connectors do not emit fetchEventTimeLag by default. In that case, when the emitEventTimeLag reports a large value, we need to know whether it is because Flink was not able to get the data from the external system, or it is because the RecordEmitter took long to process the record. The sourceIdleTime would be helpful in that case.

@rmetzger @dianfu I would like to get your opinions about getting this PR into Flink 1.12 release.
This PR adds FLIP-33 metrics support to the Source. The reasons I think we should have it in 1.12 are following:

It is the last major piece that would make the Source usable in serious case - people won't be able to actually use a connector in production if there is no metric.
If the individual connectors implement the metrics by themselves. They may find those metrics clash with the metrics that we add later.
FLIP-27 is still a relatively new feature and the patch only touches the Source. So the risk of introducing problem is low.

What do you think? Thanks.

@becketqin Fair enough for me. +1 from my side.

I generally think it is problematic to merge new features almost a week after the feature freeze. If everybody would do this, then the release would drag on forever. In particular if a change is causing build instabilities which block the release process.
However in this case, I see the feature is mostly limited to connectors (thus we can revert it in case of instabilities), and it seems that testing of the Kafka connector hasn't started yet either. I'd be okay with merging it, given the user benefits.

I just looked over the review comments so far again, and I also realized that the code doesn't even compile at this point. I'm not sure if it is really a good idea to merge this still for the 1.12 release, as it could lead to instabilities that will be difficult to debug, or API choices that will be hard to change in future releases.

@rmetzger Thanks for sharing your thoughts and concerns. I understand your concerns about merging new features after feature freeze. And I am fine with leaving this patch out of 1.12.
In case it might relieve your concern a little bit, the reason this patch did not compile was due to a race condition with another PR. And I kind of think that compared with other patches in the source, this one is probably least likely to cause instability given that it just reports metrics.

@StephanEwen As we discussed offline, I updated the patch to remove reporting of sourceIdleTime.  The only metric reported out of the box now is numRecordsIn.


Add support for client TLS and Resources to pkg/metrics

Next steps here are to change all the clients to natively export resources and call the 3-argument form of UpdateExporterFromConfigMap, then update UpdateExporterFromConfigMap to take 3 arguments and remove the to/from Resource / tags code in stackdriver_exporter.go.
/assign @anniefu @yanweiguo

@evankanderson I presume we can close this one, due to all opencensus work?