Bug: Bot device configured in this plugin as "Mode: Switch" automatically reverts to "On" state in HomeKit after each Switchbot API poll

Describe the Bug
Switchbot Bot device set as "Mode: Press" in Switchbot official app. In this plugin config that same device set to "Mode: Switch" to behave like switch On/Off persisting its state - sending "Press" command to Bot device when operating switch. When Homekit switch of this device is turned On it presses the Bot device and when turned Off it presses Bot device again. The state of switch in homekit should remain same until next pressing of switch. Current behaviour in "3.7.1 beta 10"  is that after turning the homekit switch Off it goes unexpectedly On again after next Switchbot API poll - see logs. When downgraded plugin to "3.4.0" version, it behaves as it should - when switch in homekit is Off it remains off until next switch pressing and turning it On.
To Reproduce
Bot device as  "Mode: Press" in Switchbot app, in plugin config  "Mode: Switch", turn homekit switch of this device to Off and wait until next API poll and the homekit switch goes On without any reason.
Expected Behavior
Switch in homekit should remain in current state (On/Off) until next switching and not automatically turn On based on API poll (i.e. it should persist its state until next oprating of that switch).
Relevant Log Output
[06/08/2024, 22:01:44] [SwitchBot] [DEBUG] Bot: Ohrev TUV openAPIRefreshStatus
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV statusCode: 200, deviceStatus: {"statusCode":100,"body":{"deviceId":"C63430351E48","deviceType":"Bot","hubDeviceId":"D59FD8A01843","version":"V6.6","power":"on","battery":99,"deviceMode":"pressMode"},"message":"success"}
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV statusCode: 200, deviceStatus: {"statusCode":100,"body":{"deviceId":"C63430351E48","deviceType":"Bot","hubDeviceId":"D59FD8A01843","version":"V6.6","power":"on","battery":99,"deviceMode":"pressMode"},"message":"success"}
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV openAPIparseStatus
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV (power, battery, deviceMode) = API:(on, 99, switch), current:(false, 99, switch)
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV On: true
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV BatteryLevel: 99
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV StatusLowBattery: 0
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV Firmware Version: 6.6
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV version: 6.6
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV updateHomeKitCharacteristics
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV updateCharacteristic BatteryLevel: 99
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV updateCharacteristic StatusLowBattery: 0
[06/08/2024, 22:01:46] [SwitchBot] [DEBUG] Bot: Ohrev TUV updateCharacteristic On: true

Config for homebridge-switchbot
Config of affected Bot device:

        "devices": [
            {
                "deviceId": "C63430351E48",
                "configDeviceName": "Ohrev TUV",
                "configDeviceType": "Bot",
                "connectionType": "OpenAPI",
                "bot": {
                    "mode": "switch",
                    "deviceType": "switch",
                    "doublePress": 1,
                    "pushRatePress": 5
                },
                "firmware": "6.6",
                "logging": "none"
            },

Screenshots
No response
Device and Model
Bot FW 6.6
Node.js Version
v20.16.0
NPM Version
N/A
Homebridge Version
v1.8.4
Homebridge Switchbot Plugin Version
3.7.1 beta 10
Homebridge Config UI X Plugin Version
No response
Operating System
Raspbian

Same issue here with a Smart Lock when using the latch option. I could reproduce the issue with the plugin version v3.7.0, v3.6.0, v3.5.1. It is not happening in plugin version v3.4.0.

Experiencing similar issue. This ticket looks related https://github.com/OpenWonderLabs/homebridge-switchbot/issues/1004

I think that a similar issue is happening on my ceiling lights.
In my case, homebridge's status automatically reverts to "Off" in a few seconds after turning on it using HomeKit.
But, the real ceiling light is not turned off by homebridge.

Can you try the latest beta:

Click here to find out how to install Beta

In my case, I still have the same issue on 3.7.1-beta23.
Would it help if we provide you with any logs?

logs always help

I've tried v3.7.1-beta.29 and v3.8.0.
But the ceiling lights do not work on these versions.
Loading logs using native method...
File: /var/lib/homebridge/homebridge.log: 0
[11/09/2024, 20:23:47] [SwitchBot] Plug: Mixer statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Plug",,"power":"on","version":"V2.0"},"message":"success"}
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Plug: Mixer statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Plug",,"power":"on","version":"V2.0"},"message":"success"}
[11/09/2024, 20:23:47] [SwitchBot] Plug: Mixer openAPIparseStatus
[11/09/2024, 20:23:47] [SwitchBot] Plug: Mixer (powerState) = OpenAPI: (on), current:(true)
[11/09/2024, 20:23:47] [SwitchBot] Plug: Mixer On: true
[11/09/2024, 20:23:47] [SwitchBot] Plug: Mixer Firmware Version: 2.0
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Plug: Mixer version: 2.0
[11/09/2024, 20:23:47] [SwitchBot] Plug: Mixer updateCharacteristic On: true
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Plug: Mixer On context before: true
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Plug: Mixer On context after: true
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Ceiling Light",,"power":"on","brightness":77,"colorTemperature":4425,"version":"V1.3-0.4"},"message":"success"}
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Ceiling Light",,"power":"on","brightness":77,"colorTemperature":4425,"version":"V1.3-0.4"},"message":"success"}
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light openAPIparseStatus
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light (power, brightness, colorTemperature) = OpenAPI:(on, 77, 4425), current:(on, 77, 226)
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light On: on
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light Brightness: 77
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light ColorTemperature: 226
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light Firmware Version: 1.3
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light version: 1.3
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic On: on
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context before: on
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context after: on
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Brightness: 77
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context before: 77
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context after: 77
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic ColorTemperature: 226
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context before: 226
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context after: 226
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Hue: 0
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context before: 0
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context after: 0
[11/09/2024, 20:23:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Saturation: 0
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context before: 0
[11/09/2024, 20:23:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context after: 0
[11/09/2024, 20:23:50] [Homebridge UI] Terminal session ended.
[11/09/2024, 20:23:53] [SwitchBot] Ceiling Light: Studio Light No Changes, Set On: true
[11/09/2024, 20:23:53] [SwitchBot] Ceiling Light: Studio Light openAPIpushChanges[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{"items":[{,"code":100,"status":{"fold":6,"model":"sun",,"power":"on","brightness":77,"colorTemperature":4425},"message":"success"}]},"message":"success"}
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{"items":[{,"code":100,"status":{"fold":6,"model":"sun",,"power":"on","brightness":77,"colorTemperature":4425},"message":"success"}]},"message":"success"}
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic On: true
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Brightness: 77
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic ColorTemperature: 226
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Hue: 0
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Saturation: 0
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light On: true
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light Brightness: 77
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context before: on
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context after: true
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context before: 77
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context after: 77
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context before: 226
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context after: 226
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context before: 0
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context after: 0
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context before: 0
[11/09/2024, 20:23:54] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context after: 0
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light pushBrightnessChanges
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light No changes (pushBrightnessChanges), Brightness: 77, BrightnessCached: 77
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light ColorTemperature: 226
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light pushColorTemperatureChanges
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light No changes (pushColorTemperatureChanges), ColorTemperature: 226, ColorTemperatureCached: 226
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light Hue: 0, Saturation: 0
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light pushHueSaturationChanges
[11/09/2024, 20:23:54] [SwitchBot] Ceiling Light: Studio Light No changes (pushHueSaturationChanges), Hue: 0, HueCached: 0, Saturation: 0, SaturationCached: 0[11/09/2024, 20:23:58] [Homebridge UI] Starting terminal session
[11/09/2024, 20:24:01] [Homebridge UI] Terminal session ended.
[11/09/2024, 20:24:03] [Homebridge UI] Starting terminal session[11/09/2024, 20:24:09] [SwitchBot] Ceiling Light: Studio Light openAPIRefreshStatus
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Ceiling Light",,"power":"on","brightness":77,"colorTemperature":4425,"version":"V1.3-0.4"},"message":"success"}
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Ceiling Light",,"power":"on","brightness":77,"colorTemperature":4425,"version":"V1.3-0.4"},"message":"success"}
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light openAPIparseStatus
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light (power, brightness, colorTemperature) = OpenAPI:(on, 77, 4425), current:(true, 77, 226)
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light On: on
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light Brightness: 77
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light ColorTemperature: 226
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light Firmware Version: 1.3
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light version: 1.3
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic On: on
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context before: true
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context after: on
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context before: 77
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Brightness: 77
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context after: 77
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context before: 226
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic ColorTemperature: 226
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context after: 226
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context before: 0
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Hue: 0
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context after: 0
[11/09/2024, 20:24:10] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Saturation: 0
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context before: 0
[11/09/2024, 20:24:10] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context after: 0[11/09/2024, 20:24:19] [Homebridge UI] Terminal session ended.
[11/09/2024, 20:24:21] [Homebridge UI] Starting terminal session[11/09/2024, 20:24:27] [Homebridge UI] Terminal session ended.
[11/09/2024, 20:24:29] [SwitchBot] Ceiling Light: Studio Light No Changes, Set On: true
[11/09/2024, 20:24:30] [SwitchBot] Ceiling Light: Studio Light openAPIpushChanges[11/09/2024, 20:24:30] [Homebridge UI] Starting terminal session
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{"items":[{,"code":100,"status":{"fold":6,"model":"sun",,"power":"on","brightness":77,"colorTemperature":4425},"message":"success"}]},"message":"success"}
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{"items":[{,"code":100,"status":{"fold":6,"model":"sun",,"power":"on","brightness":77,"colorTemperature":4425},"message":"success"}]},"message":"success"}
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic On: true
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Brightness: 77
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic ColorTemperature: 226
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Hue: 0
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Saturation: 0
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light On: true
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light Brightness: 77
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light pushBrightnessChanges
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light No changes (pushBrightnessChanges), Brightness: 77, BrightnessCached: 77
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light ColorTemperature: 226
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light pushColorTemperatureChanges
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light No changes (pushColorTemperatureChanges), ColorTemperature: 226, ColorTemperatureCached: 226
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light Hue: 0, Saturation: 0
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context before: on
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context after: true
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context before: 77
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context after: 77
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context before: 226
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context after: 226
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context before: 0
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context after: 0
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context before: 0
[11/09/2024, 20:24:31] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context after: 0
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light pushHueSaturationChanges
[11/09/2024, 20:24:31] [SwitchBot] Ceiling Light: Studio Light No changes (pushHueSaturationChanges), Hue: 0, HueCached: 0, Saturation: 0, SaturationCached: 0
[11/09/2024, 20:24:46] [SwitchBot] Ceiling Light: Studio Light openAPIRefreshStatus
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Ceiling Light",,"power":"on","brightness":77,"colorTemperature":4425,"version":"V1.3-0.4"},"message":"success"}
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light statusCode: 200, deviceStatus: {"statusCode":100,"body":{,"deviceType":"Ceiling Light",,"power":"on","brightness":77,"colorTemperature":4425,"version":"V1.3-0.4"},"message":"success"}
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light openAPIparseStatus
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light (power, brightness, colorTemperature) = OpenAPI:(on, 77, 4425), current:(true, 77, 226)
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light On: on
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light Brightness: 77
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light ColorTemperature: 226
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light Firmware Version: 1.3
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light version: 1.3
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic On: on
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context before: true
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light On context after: on
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Brightness: 77
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context before: 77
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Brightness context after: 77
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic ColorTemperature: 226
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context before: 226
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light ColorTemperature context after: 226
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Hue: 0
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context before: 0
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Hue context after: 0
[11/09/2024, 20:24:47] [SwitchBot] Ceiling Light: Studio Light updateCharacteristic Saturation: 0
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context before: 0
[11/09/2024, 20:24:47] [SwitchBot] [DEBUG] Ceiling Light: Studio Light Saturation context after: 0

Okay I have pushed out a new beta, this beta is a major change. all config will need to be reset and may change during the beta phase. if anyone is having any other issues with bots please try.

Click here to find out how to install Beta

Closing all issues now that v4.0.0 is out. If you are still having an issue after trying v4.0.0, please open a new issue. Keep in mind v4.0.0 has some breaking changes with the config. You will need to re set your config up, however there are some nice added bonuses since you can set settings at a deviceType level or individual level.


Add dropdown in assets list to add multiple options and features

Add dropdown to individual assets in the assets list to add more functionality besides transfer such as outside block explorer outlining.

Closing this for now - leaving metadata custom to the user side or those who wish to modify and launch the application with additional features.


Add overload with params array for AddChoiceGroup()

Adds overloads to MultiSelectionPrompt.AddChoiceGroup() and SelectionPrompt.AddChoiceGroup() taking in params T[]. Similar methods like AddChoices() had this option but these did not.
Resolves #690

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@Sir-Baconn could you please add an issue for this "problem", so we can track the changes a bit better?

@Sir-Baconn could you please add an issue for this "problem", so we can track the changes a bit better?

Thanks, I have added #690

@Sir-Baconn your changes have been merged, thanks for your contribution :+1:


[channel_posix] Don't hardcode the :authority header.

Fixes #12401.

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.
After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

User @ced5 isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

Done.

@vjpai @yang-g @sreecha, anyone know why this was hardcoded in the first place?

****************************************************************

libgrpc.so

     VM SIZE                                                                             FILE SIZE
 ++++++++++++++ GROWING                                                               ++++++++++++++

 -------------- SHRINKING                                                             --------------
  -0.0%     -16 [None]                                                                   -184  -0.0%
  -8.5%     -56 src/core/ext/transport/chttp2/client/insecure/channel_create_posix.cc     -56  -8.5%
      -8.5%     -56 grpc_insecure_channel_create_from_fd                                      -56  -8.5%

  -0.0%     -72 TOTAL                                                                    -240  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                             FILE SIZE
 ++++++++++++++ GROWING                                                               ++++++++++++++

 -------------- SHRINKING                                                             --------------
  -8.5%     -56 src/core/ext/transport/chttp2/client/insecure/channel_create_posix.cc     -56  -8.5%
      -8.5%     -56 grpc_insecure_channel_create_from_fd                                      -56  -8.5%

 -+-+-+-+-+-+-+ MIXED                                                                 +-+-+-+-+-+-+-
  +0.0%     +16 [None]                                                                   -192  -0.0%

  -0.0%     -40 TOTAL                                                                    -248  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences


Make UI responsive

Heads up, the axis helper will also need responsive positioning. It currently disappears off screen when the width is too narrow. I'll have a look later when I'm free if you don't get to it before then.

adjusted axis helper positioning


Implicit style not working after set and remove a second style

Describe the bug
I tried to add an "Error" Style to a control if has error in it's view-model, then when it's ok I remove that style as there are no error, expecting the implicit style will be applied, but no style is shown.
    <StackPanel x:Name="Stack">
        <StackPanel.Resources>
            <Style TargetType="TextBox">
                <Setter Property="Margin" Value="50"></Setter>
            </Style>

            <Style x:Name="Error" TargetType="TextBox">
                <Setter Property="Margin" Value="50"/> <!-- redefined as it's not inherit from implicit -->
                <Setter Property="Background" Value="Red"/>
            </Style>
        </StackPanel.Resources>

        <TextBox x:Name="Changing"></TextBox>
    </StackPanel>

For example I applied and remove style each second.
public sealed partial class MainWindow
{

    public MainWindow()
    {
        InitializeComponent();

        var timer = new DispatcherTimer
        {
            Interval = TimeSpan.FromMilliseconds(1000)
        };
        timer.Tick += Step;
        timer.Start();
    }

    private void Step(object sender, object e)
    {
        Changing.Style = Changing.Style == null ? Stack.Resources["Error"] as Style : null;
    }
}

Steps to reproduce the bug

Create an implicit style for TexBox
Create an explicit style for TexBox
Create a Texbox inside a window or UserControl
Change the Textbox's Style in code for the explicit style (previous value is null)
Change the Textbox's Style in code for null (initial one)
Check that Textbox doesn't have any style applied, neither the implicit one.

Expected behavior
Implicit styling should be applied after add and remove a second style
Screenshots

NuGet package version
WinUI 3 - Windows App SDK 1.1.1
Windows app type

[ ] UWP
[X] Win32

Device form factor
Desktop
Windows version
Windows 10 (21H2): Build 19044
Additional context
No response

If its not resolved I do not see why it should be closed.


Docker Image for AEM Rules

I built this: https://github.com/ahmed-musallam/sonarqube-aem
a copy of the official sonar docker image with a slight change to include AEM Rules.
to run:
docker run --rm -p 9000:9000 ahmedmusallam/sonarqube-aem:latest

Feel free to add this to the repo to get devs started quickly.
I will be writing an article on this soon as well :)

Hey @ahmed-musallam ,
thanks a lot, will add it to the readme. :-)
Send me the link to the article when it's live so I can tweet about it.

@chutch I wrote a small post about it here: https://blogs.perficientdigital.com/2019/05/15/running-a-local-sonarqube-server-with-aem-rules/


Feautre request - Export current version to a local file

Hey, thank you for developing bob!
I want to track the current nvim version I use, specifically track it using version control, so if a plugin / configuration I use stopped working after changing neovim's version, I would be able to tell so after a while if I haven't seen the issue immediately.
What's nice is that using bob install (without an argument) can now look at that configured file and install the version from there rather than expect the version. (WIth an appropriate log message)
Ideally, this would be a config, and I'd use a workflow of this sort:
bob use 0.9.0
# bob writes the 0.9.0 to a preconfigured file, let's say `/Users/user/.config/nvim/bob.version`
git add bob.version
git commit -m "neovim upgraded to 0.9.0"

Then it'd be really easy for me to see when I actually changed versions, and potentially I can also use git bisect to find out if the reason my config suddenly has issues is due to upgrading the version (of course, bob install would be needed between each step)
Right now I implemented this for myself using simple zsh wrappers around bob install, but having this as a built-in feature would be really nice.
If it's something you want to support, I'll gladly work on it and open a PR.

there is a file called used in the installation directory, does that fit your request?

Unfortunately no, for two reasons:

Unconfigurable path, I want the file to exist in my dotfiles, specifically my neovim configuration. Yes, I can configure the downloads directory path, but it means that the versions will be downloaded to the same directory, which I don't like.
Lack of implicit bob install, I would want bob install (or perhaps it should be bob use) without arguments to use the version stored in that same file, and that's not the current behavior, nor it is configurable

Hey! If you are up to the task you are free to open a PR to add a configurable path to the version file.
But don't add an implicit bob install, i personally don't like implicity.

Sure!
I'd still want to have a command that reads the version from the current version file, how about a new command, bob sync?

Sounds good, make it work like a lock file or something


[DOC] Feedback on Security topics

What do you want to do?
x Request a change to existing documentation
Community feedback from the documentation website:
Tell us about your request. Provide a summary of the request and all versions that are affected.

[ ] 20230503 |  /docs/latest/security/access-control/cross-cluster-search/ |What about other details? What if my port is proxied?

[ ] 20230505 | /docs/latest/security/audit-logs/index |
/plugins.security.audit.ignore_requests is plugins.security.audit.config.ignore_requests, and this is  the same for most of the settings

[ ] 20230526 | /docs/latest/security/authentication-backends/authc-index/ | There is no description of the configuration for Basic Auth/internal users.  There is no description of how to use multiple authentication methods together.

[x] 20230526 | /docs/latest/security/configuration/configuration/config.yml | contains element 'config' not element opensearch_security'

[x] 20230527 | docs/latest/security/configuration/configuration/ | Example root element is documented as 'opensearch_security:' when it is actually 'config:'

[ ] 20230526 |/docs/latest/security/configuration/multi-auth/ | opensearch_security.openid.scope is not described or even mentioned

[ ] 20230525 | /docs/latest/security/multi-tenancy/multi-tenancy-config/ I| s this for kibana or opensearch dashboards? n seems to override any sort filter.

[ ] 20230525 |/docs/2.7/security/multi-tenancy/dynamic-config/ |"Disable or enable multi-tenancy...The default is true"  Does that mean the default is true==disable or true==enable?

What other resources are available? Provide links to related issues, POCs, steps for testing, etc.
https://opensearch.org/docs/latest/security/index/

This PR fixes a couple of the items. https://github.com/opensearch-project/documentation-website/issues/4315

In progress by @john-eliatra

I can work on this.

PR submitted for multi-tenancy issues

20231012 | /docs/latest/security/multi-tenancy/tenant-index/ | The global tenant is not a primary tenant -> are you meaning your private tenant? -x
20230525 | /docs/latest/security/multi-tenancy/multi-tenancy-config/ | Is this for kibana or opensearch dashboards? n seems to override any sort filter.-x

PR created for  20230825 | /docs/latest/security/access-control/document-level-security/ | This document did not provide information on how edit the document level permissions.

PR created for 20231130 | /docs/latest/security/configuration/system-indices/ | "When Security is installed" is not a helpful condition. If one asks "How to install security" using the built in search at the top "When Security is installed" is not a helpful condition. If one asks "How to install security" using the built in search at the top of the page one gets a long list of "hits". None of the top ones seems to answer the questions and studying all of them would take days. So the list of hits is actually worthless.Please underpin the phrase with a link. (in progress)

@hdhalter please assign me to this issue.

I've been looking into 20230811 | /docs/latest/security/access-control/permissions/ | No example code, from reading through the page, there are examples given. There are lists provided such as, Alerting Permissions, Asynchronous Search permissions, Index State Management permissions, etc. At the top of those lists there are links to the relevant page where the examples are given e.g. Alerting Permissions shows the link See Alerting API where the examples are given in further depth on the relevant page. cc @hdhalter

Thanks for looking at this, @leanneeliatra ! There were some updates to that topic after the comment was made. Let's close that one.

Brilliant thank you @hdhalter

All feedback has been addressed. Thanks, @AntonEliatra and @leanneeliatra !


tailwind compatibility ?

I noticed that there are no box shadows included.  Is there perhaps a comparison table of the compatibility with tailwind ? Or should it be 100% ?

There are box shadows supported, shadow-md, -lg, -xl etc. Please let me know which class has problems.

Sorry for the delay - not sure why it didn't show up - i got the shadow working.
But now i see another one;
border-x and border-y
Should these be working ?

You are right. border-x/y is missing. They are added in the latest version 1.1.5

@xinjie-zhang would it be possible to include the tailwind filters  as well ?

I was trying to fork & update the code to include filters, but I understand only a single filter: property can exist on a element and they would need to be combined in a single string. Is there a way to capture those and combine them ?
i had something like this
  // filter - saturation
  R(`saturate-`, (classDetails) => {
    let parts = classDetails.name.split("-")
    return `filter: saturate(${(+parts[1] / 200) * 2});`
  })

  // filter - hue rotate
  R(`hue-rotate-`, (classDetails) => {
    let parts = classDetails.name.split("-")
    return `filter: hue-rotate(${+parts[1]}deg);`
  })

but applying them both wouldnt work.

Hi @bakman2  actually the filter could be implemented like transform. The basic idea is to use css vars. the R/register has the third argument initFunc : register(keys, generatorOrStyle, initFunc). It means when this class is added, it should add some init code, like the transform/filter css vars' init value.


Update inja v3.4.0

inja switch to c++17 after v3.4.0 https://github.com/pantor/inja/releases/tag/v3.4.0, that will cause add_requires("inja master")
so fix it

reopen for workflow (

Well, the FreeBSD workflow is functioning normally on my test branch without code change， https://github.com/MarcusMogg/xmake-repo/actions/workflows/freebsd.yml


always tag instances with managed tags and provisioner tags

1. Issue, if available:
https://github.com/awslabs/karpenter/issues/793
2. Description of changes:

Tag all fleet launches w/ managed tags and provisioner tags. Previously this only worked when using the LT that karpenter generates. This now works with custom LTs.

3. Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: link to issue
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

🚢 ❗


[QA] naming of security settings is negative

Seen in ocis 4.0.0 and before
We currently have an environment variable OCIS_INSECURE which needs to be set to false, when securing the ssl connection with a certificate.
We also have a init option --inscecure to allow an unencrypted internal communication between proxy and ocis.
I suggest to instead use a variable OCIS_SECURE=true
and an init option --trusted-network or similar.
@hodyroff @tbsbdr does this cover, what we just discussed?

@jnweiger thanks for the feedback.
I agree with the general idea, BUT: just renaming a crucial variable and going through all the deprecation process just to make it "nicer" is IMO questionable.

We currently have an environment variable OCIS_INSECURE which needs to be set to false, when securing the ssl connection with a certificate.

Just to be clear: OCIS_INSECURE does not need to be set at all, when using a valid certificate (it defaults to false). The secure behavior is the default (if that is not the case, there's a bug somewhere that we need to fix).
So the insecure behavior has to be explicitly requested by the user. I don't see anything wrong with also naming that option insecure then.
Also, requiring the user to explicitly set INSECURE/ insecure to disable certificate verification is AFAICT a pretty  broadly established practice and used in a ton of other projects.

Only if we are going to address this, we could, to relax any deprecation needs, add a global envvar named: OCIS_SECURE with inverse behaviour in parallel to OCIS_INSECURE. The rest is a docs issue.

i agree with @rhafer
Naming is clear.


Update Experiment-Analysis-Point-Solution.md

🚀 Deployed on https://63e53bcedf52521678e0e3b7--cozy-fox-0defec.netlify.app


Support building with LLVM 18

This helps in building bpftrace with upcoming LLVM 18 release.
Checklist

[x] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[x] The new behaviour is covered by tests

Looks like llvm 18 comes out in march: https://discourse.llvm.org/t/llvm-18-release-schedule/76175
Doesn't seem like they'll make further API tweaks so we are probably good to land this now and add CI later

Bump; looks like fedora is shipping llvm 18 already: https://github.com/bpftrace/bpftrace/actions/runs/8177304598/job/22358684815

I've rebased and taken over the changes in #3051


VIRTUAL SET 17! Plus rulings and fixes.

Also added some abbreviations because Tom recently made them searchable by default (e.g. you can type HCF right in the title box and it works!)


Better alignment of language selector

In master.xhtml. There's a not so elegant  and on small screens the EN and IT text ends up on different lines and misaligned.
Also adding "Language:" before would make their purpose more clear, maybe?

It seems reasonable. Please, make a pull request.


Game submission: Destroy!

Here is the entry for Ultrarare
Contributors are
lambertjamesd#3921
nick12355#0265
pixelcrustpunk#7095
SapphireTactics#7972
jtn191#1500

Thank you for your submission!

Merged to main into the unified ROM.


kthread_create hangs waiting on semaphore while trying to copy file descriptors

In developing my CAN driver for the Tiva chips, I decided to use a kernel thread to load messages from the RX mailboxes. I call kthread_create like this:
ret = kthread_create("Tiva CAN0", CONFIG_TIVA_CAN0_PRIO,
                                TIVA_CAN_KTHREAD_STACKSIZE, tivacan_rxhandler,
                                kthd_argv);

where kthd_argv is a string vector with a terminating null entry as specified in the comments for kthread_create. This is done in tivacan_setup(), which is called by can_open(). However, kthread_create() hangs in file_dup2(); for some reason it copies 3 file descriptors (stdin, stdout, stderr, I suppose) then hangs waiting for a semaphore. This should not happen—kthreads should not even have memory allocated for open file descriptors.

@MTres19  Can you point to the semaphore that it is hanging on?
Also slightly unrelated to the issue at hand, but it seems like you might be wanting to use the low/highpriority worker thread mechanism that most of the other drivers use for scheduling rx/tx work.

@MTres19  Can you point to the semaphore that it is hanging on?
Also slightly unrelated to the issue at hand, but it seems like you might be wanting to use the low/highpriority worker thread mechanism that most of the other drivers use for scheduling rx/tx work.

Hi @btashton yep, I think it's the semaphore for the list of open file descriptors in the task control that's being initialized. struct tcb_s.group->tg_filelist.fl_sem. But I'm not familiar with the code so it's hard to see the big picture... the relevant line in my driver is here if you're curious. I assume this problem hasn't come up before because most drivers wouldn't create a kernel thread in a function that's called from the application.
This "fixes" the problem for me but it's just a band-aid I know.
diff --git a/sched/task/task_init.c b/sched/task/task_init.c
index b187b74ebe..3e3fd61a45 100644
--- a/sched/task/task_init.c
+++ b/sched/task/task_init.c
@@ -101,11 +101,14 @@ int nxtask_init(FAR struct task_tcb_s *tcb, const char *name, int priority,
     }

   /* Associate file descriptors with the new task */
-
-  ret = group_setuptaskfiles(tcb);
-  if (ret < 0)
+
+  if (!(ttype & TCB_FLAG_TTYPE_KERNEL))
     {
-      goto errout_with_group;
+      ret = group_setuptaskfiles(tcb);
+      if (ret < 0)
+        {
+          goto errout_with_group;
+        }
     }

   if (stack)

Based on this comment.
Regarding a dedicated thread vs the work queue, I actually do use the low-priority work queue to check periodically for bus errors when servicing the interrupt would be excessive. I read the admonition against using the work queue for things like this on the wiki.

Hi @btashton yep, I think it's the semaphore for the list of open file descriptors in the task control that's being initialized. struct tcb_s.group->tg_filelist.fl_sem. But I'm not familiar with the code so it's hard to see the big picture... the relevant line in my driver is here if you're curious. I assume this problem hasn't come up before because most drivers wouldn't create a kernel thread in a function that's called from the application.
This "fixes" the problem for me but it's just a band-aid I know.
diff --git a/sched/task/task_init.c b/sched/task/task_init.c
index b187b74ebe..3e3fd61a45 100644
--- a/sched/task/task_init.c
+++ b/sched/task/task_init.c
@@ -101,11 +101,14 @@ int nxtask_init(FAR struct task_tcb_s *tcb, const char *name, int priority,
     }

   /* Associate file descriptors with the new task */
-
-  ret = group_setuptaskfiles(tcb);
-  if (ret < 0)
+
+  if (!(ttype & TCB_FLAG_TTYPE_KERNEL))
     {
-      goto errout_with_group;
+      ret = group_setuptaskfiles(tcb);
+      if (ret < 0)
+        {
+          goto errout_with_group;
+        }
     }

   if (stack)

Based on this comment.
Regarding a dedicated thread vs the work queue, I actually do use the low-priority work queue to check periodically for bus errors when servicing the interrupt would be excessive. I read the admonition against using the work queue for things like this on the wiki.

The issue with using a worker thread for what you have is that you have a while loop that waits on a semaphore
https://github.com/MTres19/incubator-nuttx/blob/b63c54bb52f4158c6495723359032668f0947080/arch/arm/src/tiva/common/tiva_can.c#L731
This is a great place to use a a worker thread.
Right here you currently are signalling your kernel thread to do work, instead you can schedule work work.
https://github.com/MTres19/incubator-nuttx/blob/b63c54bb52f4158c6495723359032668f0947080/arch/arm/src/tiva/common/tiva_can.c#L1791
work_queue(HPWORK, &priv->cbwork, (worker_t)priv->callback,
           priv->cbarg, 0);

Note that the arg is stored in the device structure.  This is one issue with what you are doing right now with your kernel thread, you are passing arguments that are allocated on the stack so they do not have have the proper lifecycle for the thread.

The issue with using a worker thread for what you have is that you have a while loop that waits on a semaphore
https://github.com/MTres19/incubator-nuttx/blob/b63c54bb52f4158c6495723359032668f0947080/arch/arm/src/tiva/common/tiva_can.c#L731
This is a great place to use a a worker thread.
Right here you currently are signalling your kernel thread to do work, instead you can schedule work work.
https://github.com/MTres19/incubator-nuttx/blob/b63c54bb52f4158c6495723359032668f0947080/arch/arm/src/tiva/common/tiva_can.c#L1791
work_queue(HPWORK, &priv->cbwork, (worker_t)priv->callback,
           priv->cbarg, 0);

Note that the arg is stored in the device structure.  This is one issue with what you are doing right now with your kernel thread, you are passing arguments that are allocated on the stack so they do not have have the proper lifecycle for the thread.

If you really want to keep using the kernel thread for performance reasons, You should be able to just move that initialization to the driver bring up and it will just be stuck waiting on the semaphore.

If you really want to keep using the kernel thread for performance reasons, You should be able to just move that initialization to the driver bring up and it will just be stuck waiting on the semaphore.

Thanks for the input @btashton. I'm still not sure I like the idea of shoving things onto the work queue though, especially since the Tiva ADC driver already uses it. For example, in my application I want to short a sensor to ground, measure a different sensor to ensure the two sensors aren't shorted together, and then release the first sensor before the external analog plausibility logic detects it. If a bunch of CAN messages happened to come in and block the work queue in the middle of that, I imagine there could be problems.
But regarding the kernel thread... isn't argv copied to the new thread's TCB? It seems like it should be safe to use stack memory to pass the arguments in that case. I agree I could move the kernel thread without much trouble but I think there is still a bug here nonetheless.

Thanks for the input @btashton. I'm still not sure I like the idea of shoving things onto the work queue though, especially since the Tiva ADC driver already uses it. For example, in my application I want to short a sensor to ground, measure a different sensor to ensure the two sensors aren't shorted together, and then release the first sensor before the external analog plausibility logic detects it. If a bunch of CAN messages happened to come in and block the work queue in the middle of that, I imagine there could be problems.
But regarding the kernel thread... isn't argv copied to the new thread's TCB? It seems like it should be safe to use stack memory to pass the arguments in that case. I agree I could move the kernel thread without much trouble but I think there is still a bug here nonetheless.

Tiva ADC driver already uses it. For example, in my application I want to short a sensor to ground, measure a different sensor to ensure the two sensors aren't shorted together, and then release the first sensor before the external analog plausibility logic detects it. If a bunch of CAN messages happened to come in and block the work queue in the middle of that, I imagine there could be problems.

I don't see how this will be an issue, your driver should only have work scheduled once on the work queue.  The logic you have in that thread is very small, small enough that most of the other CAN drivers just handle calling can_receive right in the interrupt handler.  Where it is bad is if you have a worker callback that waits on semaphore or polls on a ready/busy register.  I did not see either of these cases here.  So if you get a bunch of ADC work CAN work come in at the same time they should be equally scheduled and you may actually pay less in context switching.

But regarding the kernel thread... isn't argv copied to the new thread's TCB? It seems like it should be safe to use stack memory to pass the arguments in that case. I agree I could move the kernel thread without much trouble but I think there is still a bug here nonetheless.

You are right that is handled by nxtask_setup_stackargs I was thinking about something else.
I am not disagreeing yet that there might be a bug, just pointing out how what you are doing is different than how most other drivers are written and that I don't really see the benefit (I see a drawback in resource usage).

Tiva ADC driver already uses it. For example, in my application I want to short a sensor to ground, measure a different sensor to ensure the two sensors aren't shorted together, and then release the first sensor before the external analog plausibility logic detects it. If a bunch of CAN messages happened to come in and block the work queue in the middle of that, I imagine there could be problems.

I don't see how this will be an issue, your driver should only have work scheduled once on the work queue.  The logic you have in that thread is very small, small enough that most of the other CAN drivers just handle calling can_receive right in the interrupt handler.  Where it is bad is if you have a worker callback that waits on semaphore or polls on a ready/busy register.  I did not see either of these cases here.  So if you get a bunch of ADC work CAN work come in at the same time they should be equally scheduled and you may actually pay less in context switching.

But regarding the kernel thread... isn't argv copied to the new thread's TCB? It seems like it should be safe to use stack memory to pass the arguments in that case. I agree I could move the kernel thread without much trouble but I think there is still a bug here nonetheless.

You are right that is handled by nxtask_setup_stackargs I was thinking about something else.
I am not disagreeing yet that there might be a bug, just pointing out how what you are doing is different than how most other drivers are written and that I don't really see the benefit (I see a drawback in resource usage).

I just realized there might already be work ongoing on this in #2661.

I just realized there might already be work ongoing on this in #2661.

That makes sense. I hadn't thought much about the context switch overhead. I did originally just call can_receive in the ISR but I realized that kinda defeated the purpose of a hardware RX FIFO. I might switch it to use a work queue then.

That makes sense. I hadn't thought much about the context switch overhead. I did originally just call can_receive in the ISR but I realized that kinda defeated the purpose of a hardware RX FIFO. I might switch it to use a work queue then.

@MTres19 when do your kthread get created? Is it before idle task setup?
https://github.com/apache/incubator-nuttx/blob/master/sched/init/nx_start.c#L767

I just realized there might already be work ongoing on this in #2661.

Yes, this patch may help you.

@MTres19 when do your kthread get created? Is it before idle task setup?
https://github.com/apache/incubator-nuttx/blob/master/sched/init/nx_start.c#L767

I just realized there might already be work ongoing on this in #2661.

Yes, this patch may help you.

It's in tivacan_setup, which gets called when the char device is opened, so
it tries to inherit the app's file descriptors.
On Sun, Jan 10, 2021, 3:27 AM Xiang Xiao<EMAIL_ADDRESS>wrote:

@MTres19 https://github.com/MTres19 when do your kthread get created?
Is it before idle task setup?
https://github.com/apache/incubator-nuttx/blob/master/sched/init/nx_start.c#L767
I just realized there might already be work ongoing on this in #2661
https://github.com/apache/incubator-nuttx/pull/2661.
Yes, this patch may help you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-nuttx/issues/2663#issuecomment-757438035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEKWLADPC7OHAS47FMONSETSZFQGDANCNFSM4V3UVI6Q
.

It's in tivacan_setup, which gets called when the char device is opened, so
it tries to inherit the app's file descriptors.
On Sun, Jan 10, 2021, 3:27 AM Xiang Xiao<EMAIL_ADDRESS>wrote:

@MTres19 https://github.com/MTres19 when do your kthread get created?
Is it before idle task setup?
https://github.com/apache/incubator-nuttx/blob/master/sched/init/nx_start.c#L767
I just realized there might already be work ongoing on this in #2661
https://github.com/apache/incubator-nuttx/pull/2661.
Yes, this patch may help you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-nuttx/issues/2663#issuecomment-757438035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEKWLADPC7OHAS47FMONSETSZFQGDANCNFSM4V3UVI6Q
.

so it happen very late, then it's strange that file_dup2 fail to acquire the semphare.

so it happen very late, then it's strange that file_dup2 fail to acquire the semphare.

@xiaoxiang781216 I just noticed something similar when trying to create a kernel thread off of a call in sim_bringup() (I'm add usbhost support via libusb).  I get a segfault because in sched_dupfiles rtcb->group is 0 which means parent and child are both invalid
Thread 1 "nuttx" received signal SIGSEGV, Segmentation fault.
                                                             sched_dupfiles (tcb=0x7ffff3e295d0) at group/group_setuptaskfiles.c:103
103           if (parent[i].f_inode &&
Missing separate debuginfos, use: dnf debuginfo-install libgcc-10.2.1-9.fc33.x86_64 libusbx-1.0.23-2.fc33.x86_64 systemd-libs-246.7-2.fc33.x86_64 zlib-1.2.11-23.fc33.x86_64
(gdb) p parent
$1 = (struct file *) 0x78
(gdb) list
98            /* Check if this file is opened by the parent.  We can tell if
99             * if the file is open because it contain a reference to a non-NULL
100            * i-node structure.
101            */
102
103           if (parent[i].f_inode &&
104               (parent[i].f_oflags & O_CLOEXEC) == 0)
105             {
106               /* Yes... duplicate it for the child */
107
(gdb) p rtcb
$2 = (struct tcb_s *) 0x7ffff3e27c90
(gdb) p rtcb->group
$3 = (struct task_group_s *) 0x0
(gdb) p rtcb*
A syntax error in expression, near `'.
(gdb) p *rtcb
$4 = {flink = 0x43f8a0 <g_idletcb>, blink = 0x7ffff7f38020 <_IO_strn_jumps>, group = 0x0, pid = 1, start = 0x402184 <nxtask_start>, entry = {pthread = 0x408e78 <nsh_main>, main = 0x408e78 <nsh_main>}, sched_priority = 100 'd',
  init_priority = 100 'd', task_state = 3 '\003', flags = 0, lockcount = 0, errcode = 0, waitdog = {next = 0x0, func = 0x85b82ce26aee8900, lag = 0, flags = 0 '\000', arg =<PHONE_NUMBER>727424768}, adj_stack_size =<PHONE_NUMBER>94944,
  stack_alloc_ptr = 0x85b82ce26aee8900, adj_stack_ptr = 0x4412a0, waitsem = 0x0, sigprocmask =<PHONE_NUMBER>, sigwaitmask = 32767, sigpendactionq = {head = 0x4412a0, tail = 0xffffffff}, sigpostedq = {head = 0x3, tail = 0x4441d0}, sigunbinfo = {
    si_signo = 5 '\005', si_code = 23 '\027', si_errno = 232 '\350', si_value = {sival_int = 48, sival_ptr = 0x3000000030}, si_pid = 32304, si_status = 32767}, msgwaitq = 0x7ffff3e27d60, mhead = 0x85b82ce26aee8900, xcp = {
    sigdeliver = 0x7ffff3e27e1c, regs = {4539616, 0, 0, 0,<PHONE_NUMBER>13158, 4473296,<PHONE_NUMBER>99557,<PHONE_NUMBER>96080}}, name = "x\030\371\367\377\177\000\000\000\000\000\000\000\000\000\000 \203\363\367\t\000\000\000\340DE\000\000\000\000"}
(gdb) p rtcb->group
$5 = (struct task_group_s *) 0x0

@xiaoxiang781216 I just noticed something similar when trying to create a kernel thread off of a call in sim_bringup() (I'm add usbhost support via libusb). I get a segfault because in sched_dupfiles rtcb->group is 0 which means parent and child are both invalid

This is probably running on the IDLE thread which has no parent and the PID for the IDLE thread always zero.  Zero does not mean invalid anywhere except in the case of the parent PID here.
The meaning PID of zero is overloaded elsewhere too:  In several POSIX APIs, PID == 0 means "this task."  But that is not an issue here.

Just try the same code in my environment, rtcb->group point to the good value:

I suspect that you may hit some memory corruption, could you just try to create a kernel thread without linking with libusb?

Hmm, you might be right, I could not find anything else that made sense when I was looking last night.    The library does get initialized in the parent thread which could use a fair bit of the stack.  The memory around group looked good which is why I did not suspect this, but I'll mess with it again tonight.

So taking a fresh look at this and not being quite so pressed for time, I would like to discuss what the correct fix for this bug would be. Restated, the problem is:
App calls open() → can_open() → tivacan_open(), which calls kthread_create(). kthread_create calls nxthread_create() which allocates the thread control block, sets the thread type to kernel and calls nxtask_init(). nxtask_init() does the following:

Allocates a new task group with group_allocate(). group_allocate allocates memory on the heap but it also copies the UID, GID, and environment of the current task to the new task. That doesn't make sense for kernel threads.
Copies file descriptors for the task group with group_setuptaskfiles(). Again this tries to copy userspace file descriptors to the kernel thread which is wrong.
Does some other initialization stuff
Calls group_initialize() to finish the setup.

To me it seems kernel threads should have a different task group struct that excludes at least tg_filelist, tg_streamlist, tg_envsize, and tg_envp. Or at least these should not be initialized for kernel threads. The latter option would be easy, like the band-aid patch I already posted.
It also seems that kernel threads should have their UID and GID set to 0 instead of inheriting it.
Are these accurate conclusions? Given a recommendation I could submit a PR.

To me it seems kernel threads should have a different task group struct that excludes at least tg_filelist, tg_streamlist, tg_envsize, and tg_envp. Or at least these should not be initialized for kernel threads. The latter option would be easy, like the band-aid patch I already posted
You are right.  There is no purpose in having most of those things in a kernel thread since they cannot have pthreads and, hence, can't really have a task group.  See Why Can't Kernel Threads Have pthreads? - NUTTX - Apache Software Foundation.

|
|
|  |
Why Can't Kernel Threads Have pthreads? - NUTTX - Apache Software Founda...
|
|
|
There are other complications like:  What if a kernel thread creates a user task?  The inheritance of file descriptors, stdio I/O and the environment will get a lot more complex.
The current design does save a lot of code duplication by re-using all of the user-space task structures.

It also seems that kernel threads should have their UID and GID set to 0 instead of inheriting it.
Yes, but there is not fully developed user-based security in the OS so it would end up being mostly cosmetic.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: @.***>

How about skip some normal setup(e.g. fd dup) from kernel thread creation?

How about skip some normal setup(e.g. fd dup) from kernel thread creation?

Well, it fixes the problem but like I said it's just a bandaid. A shortcut, rather than addressing the real problem. IMO better to leave this and #1108 open and I'll carry the patch downstream. Then we could work on a proper fix with all the necessary testing.

More people hit the similar issue, let's fix it by skip the dup now(https://github.com/apache/incubator-nuttx/pull/5379) until we get the better solution.

More people hit the similar issue, let's fix it by skip the dup now(#5379) until we get the better solution

If we merge https://github.com/apache/incubator-nuttx/pull/5379 then should we create a new issue to "get a better solution"?

We can track the better solution by https://github.com/apache/incubator-nuttx/issues/1108?


add support for statestore query API

This feature is implemented in dapr runtime: dapr/dapr#3662
It should be available via the SDK

Closing in favour of #115


dev-job-in-job branch: False positives on cycle detection

 Issue by rclough
Thursday Jan 07, 2016 at 20:40 GMT
Originally opened as https://github.com/thieman/dagobah/issues/172

Want to note this here cause I might not be able to immediately address it.
To replicate:

Create "Job A" with trivial task "ls"
Create "Job B" and
Add "Job A" as a jobtask to "Job B"
Add it again, with a new name
Add a dependency betweenthe tasks
Attempt to run
Receive "Unable to start job"

In laymans terms, if you want to make a job that executes another job, twice in a row, which is entirely valid, it will assume it has a cycle.
For whatever reason, the job is not removed from the "context", which denotes which job expansions you are currently running in. I suspect this is due to a poor pass by reference/value assumption

 Comment by rclough
Thursday Jan 07, 2016 at 21:47 GMT

I've looked at this again, and some discussion here: https://github.com/thieman/dagobah/issues/60#issuecomment-42970039
I think the issue is that the context needs to be treated as "immutable". Right now the code looks like (highly simplified):
    def verify(self, context=none):
        if context is none:
            logger.debug("no context set, using empty set")
            context = set()
        if self.name in context:
            return false
        context.add(self.name)

        # Topological sort verifies DAG is acyclic before digging deeper
        ...

        # Traverse nodes and verify any JobTasks
        for task in topo_sorted:
            if not self.implements_expandable(task):
                continue
            cur_job = self.parent._resolve_job(task.target_job_name)
            if cur_job.name in context:
                return False

            # Verify this job has no internal cycles, or references to jobs
            # in the current context
            verified = cur_job.verify(context)
            if not verified:
                return False

        return True

I did some additional debug logging, and what happens is the verify() returns from the first instance of  "Job A", but is never removed from the context before attempting to verify the next.
The initial discussion (linked above) seems to assume pass-by-value in passing the context, which is not the case (unless I'm missing some nuance)
I see two main options, but am open to other ideas:

only pass a copy of the context (ie force pass-by-value)
manually remove yourself from the context before returning True at the end of verify. This should work because all other returns would be False or an Error.

Thoughts?

 Comment by rclough
Thursday Jan 07, 2016 at 22:41 GMT

I personally think the best way is #2, which just results in the following line, before the final return True above:
context.discard(self.name)

Should be "guaranteed" (:wink:) to work because discard() does not fail on missing key, and self.name is exactly what's added right at the beginning.
Tested it by hand and seems to work, passes existing tests as well.


Add files

hey @Astrodevil .
I have added some cpp pdfs for resources.
please merge those pdfs.
Thanks in advance.

@Rimjhim20 Add pdf resources in directory like "Free-resources/C++/pdfs/put your all pdfs"

Ok sure. thank you 🙂
On Sat, Oct 2, 2021, 2:47 PM Mr. Ånand @.***> wrote:

@Rimjhim20 https://github.com/Rimjhim20 Add pdf resources in directory
like "Free-resources/C++/pdfs/put your all pdfs"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Astrodevil/Programming-Basics/pull/119#issuecomment-932720504,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARCRO3MQSLTCX3RQVUS5GMTUE3E2FANCNFSM5FDZMSWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

hey @Astrodevil  yes this is for hacktoberfest. I made changes accordingly so now plz merge this.
Thank you.

hey @Astrodevil yes this is for hacktoberfest. I made changes accordingly so now plz merge this. Thank you.

Everything is fine, but it looks like you put file name .pdf.pdf in hurry. let me know if any problem arises due to this.

No it's will not create any issue.
On Sat, Oct 2, 2021, 4:15 PM Mr. Ånand @.***> wrote:

hey @Astrodevil https://github.com/Astrodevil yes this is for
hacktoberfest. I made changes accordingly so now plz merge this. Thank you.
Everything is fine, but it looks like you put file name .pdf.pdf in hurry.
let me know if any problem arises due to this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Astrodevil/Programming-Basics/pull/119#issuecomment-932730905,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARCRO3JCXRTTKH6NRHX3TADUE3PENANCNFSM5FDZMSWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

It automatically changed via uploading in . Pdf. So kindly ignore. All pdf
are working fine I guess.
On Sat, Oct 2, 2021, 4:26 PM Rimjhim Kumari @.***>
wrote:

No it's will not create any issue.
On Sat, Oct 2, 2021, 4:15 PM Mr. Ånand @.***> wrote:

hey @Astrodevil https://github.com/Astrodevil yes this is for
hacktoberfest. I made changes accordingly so now plz merge this. Thank you.
Everything is fine, but it looks like you put file name .pdf.pdf in
hurry. let me know if any problem arises due to this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Astrodevil/Programming-Basics/pull/119#issuecomment-932730905,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARCRO3JCXRTTKH6NRHX3TADUE3PENANCNFSM5FDZMSWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thanks 😊
On Sat, Oct 2, 2021, 4:28 PM Mr. Ånand @.***> wrote:

Merged #119 https://github.com/Astrodevil/Programming-Basics/pull/119
into main.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Astrodevil/Programming-Basics/pull/119#event-5398041613,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARCRO3I5Y7MVQPXTNMZEMULUE3QVNANCNFSM5FDZMSWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


⚠ T:Riza Api has degraded performance

In b19bf86, T:Riza Api (https://infra.triza.dev/api) experienced degraded performance:

HTTP code: 200
Response time: 3915 ms

Resolved: T:Riza Api performance has improved in 3559d0f.


perf: Implement filtering in New Chat page

Details

This is the continuation of moving from getSearchText to filtering the lists. Here we are migrating the logic in New Chat page
Fixed Issues

$ https://github.com/Expensify/App/issues/44634
PROPOSAL:
Tests

Press global create and select "New chat"
Type something that matches any of the options existing on your list
Verify option is displayed after finished typing
Verify the list has the same options in the same order as the same search text applied on main branch
Clean the input and type a random email that does not exist on the list
Verify the email appears on the list if it's valid

[x] Verify that no errors appear in the JS console

Offline tests

n/a
QA Steps

Press global create and select "New chat"
Type something that matches any of the options existing on your list
Verify option is displayed after finished typing
Clean the input and type a random email that does not exist on the list
Verify the email appears on the list if it's valid

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/13985840/a7534410-c924-4d85-bb09-661d1a3607f1

Android: mWeb Chrome
https://github.com/Expensify/App/assets/13985840/01cf22c5-b7a7-43eb-b570-a5601e73a321

iOS: Native
https://github.com/Expensify/App/assets/13985840/a98417bd-af03-49a6-b3bd-7a6cbc6dae24

iOS: mWeb Safari
https://github.com/Expensify/App/assets/13985840/2ae4d4d6-5ef1-43bd-868b-342243358325

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/13985840/40ef18e4-23c7-4d1e-8ce3-c371ef74e41a

MacOS: Desktop
https://github.com/Expensify/App/assets/13985840/2b5aef0b-a509-4f38-b2cf-75a2e4684590

To be opened once #40285 gets merged - it's sharing the same logic for inviting a user as in the mentioned PR

I'm seeing you linked closed issue. Is that correct PR? 🤯

@hungvu193 this PR (and a few others) was in draft for pretty long time because it was waiting for #40235 to be merged first. I can see the issue was closed after merging it during my PTO 🤔 What should we do then? Should we create a new issue to link all of those PRs?

I think we should create another issue for this PR, Yes.
Let's me approve to pull internal engineer here.

@roryabraham Can you take a look at the comment above? TIA

@hungvu193 created https://github.com/Expensify/App/issues/44634 for this. @TMisiukiewicz can you please comment for assignment?

@roryabraham commented and updated issue in the PR description, thank you 👍

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/16502320/36ad7e5c-66a1-4f9a-8b21-aa5af6804414

Android: mWeb Chrome

https://github.com/Expensify/App/assets/16502320/1159c3bf-0678-48b4-a0f6-c0260eef9589

iOS: Native

https://github.com/Expensify/App/assets/16502320/bdbaa7c4-4334-47b8-a6b1-70d479ee5d7a

iOS: mWeb Safari

https://github.com/Expensify/App/assets/16502320/1033b1ff-e1c9-4710-97d0-4113c98de186

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/16502320/a25a823f-308f-471c-ad83-02b1ef49a083

MacOS: Desktop

https://github.com/Expensify/App/assets/16502320/9de6dbe0-a1fa-4429-a320-5a39ecbe67ea

updated branch with latest main

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/roryabraham in version: 9.0.6-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/roryabraham in version: 9.0.6-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Cherry-picked to staging by https://github.com/Julesssss in version: 9.0.6-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Cherry-picked to staging by https://github.com/Julesssss in version: 9.0.6-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/thienlnam in version: 9.0.6-8 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/thienlnam in version: 9.0.7-8 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Library doesn't work with Nette/di v3.0.0-RC2

Since yesterday evening I got the following error on https://travis-ci.org/BurdaMagazinOrg/thunder-distribution/jobs/511585322:
PHP Fatal error:  Uncaught Nette\MemberAccessException: Call to undefined method Nette\DI\Definitions\ImportedDefinition::getFactory(). in /home/travis/build/BurdaMagazinOrg/test-dir/vendor/nette/utils/src/Utils/ObjectHelpers.php:65
Stack trace:
#0 /home/travis/build/BurdaMagazinOrg/test-dir/vendor/nette/utils/src/Utils/SmartObject.php(42): Nette\Utils\ObjectHelpers::strictCall('Nette\\DI\\Defini...', 'getFactory')
#1 /home/travis/build/BurdaMagazinOrg/test-dir/vendor/mglaman/phpstan-drupal/src/DependencyInjection/DrupalExtension.php(71): Nette\DI\Definitions\Definition->__call('getFactory', Array)
#2 /home/travis/build/BurdaMagazinOrg/test-dir/vendor/nette/di/src/DI/Compiler.php(233): PHPStan\DependencyInjection\DrupalExtension->loadConfiguration()
#3 /home/travis/build/BurdaMagazinOrg/test-dir/vendor/nette/di/src/DI/Compiler.php(185): Nette\DI\Compiler->processExtensions()
#4 /home/travis/build/BurdaMagazinOrg/test-dir/vendor/nette/di/src/DI/ContainerLoader.php(119): Nette\DI\Compiler->compile()
#5 /home/travis/build/BurdaMa in /home/travis/build/BurdaMagazinOrg/test-dir/vendor/nette/utils/src/Utils/ObjectHelpers.php on line 65

Looks like they changed something and broke the API

There are also problems in https://github.com/phpstan/phpstan/issues/2033

Here is a PR
https://github.com/mglaman/phpstan-drupal/pull/48


This site can’t be reached

I made a small express server with the following code
const express = require("express");
const app = express();
const port = 5000;

app.get("/", (req, res) => {
        res.send("Hello")
});

app.listen(port, () => {
        console.log(`Listening on port: ${port}`)
});

and it currently is running on my Ubuntu 18.04.4 LTS x86_64 vps and when i go to https://<my vps ipv4>:5000, im getting This site can’t be reached.
How could i fix this?
i have allowed the port on ufw and ive allowed it with iptables but i dont know why this isn't working. I have also ran sudo tcpdump -i ${ext_if} port 5000 to dump information about the port and that shows information about my connection but im getting This site can’t be reached.

Hi @SerenModz21! Your code seems fine. It is working as expected in my machine. 👍
I asume the issue is related to your VPS Provider. Maybe you need to perform extra steps in the configuration to allow incoming traffic at port 5000?

I contacted my vps provider and they thought express was binding the port locally

@UlisesGascon Thank you for ur help, i spoke to my vps provider and we sorted it, i just had to reset my firewall records


The plugin seems to crash IDEA 2018.2.5

See https://youtrack.jetbrains.com/issue/IDEA-201030

This is not a plugin issue, It's JRE (Native crash) issue of IntelliJ platform. https://youtrack.jetbrains.com/issue/JRE-855


fix(receive): refresh onchain wallet after receive

Description
Refresh onchain wallet on transactionReceived
Linked Issues/Tasks
Closes https://github.com/synonymdev/bitkit/issues/2078
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactoring (improving code without creating new functionality)

Tests

[ ] Detox test
[ ] Unit test
[x] No test

Screenshot / Video
https://github.com/user-attachments/assets/a892a4ad-fb15-4e70-9185-2ae1a3de3051

I was hoping to fix this in beignet, give me a couple more days


User was signed out while using the desktop app when login in Web

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Expected Result:
User should not be signed out while using the app.
Actual Result:
User was signed out of the app while sending a message. Sent message was not displayed after signing back in.
More information from @mallenexpensify thread:

Saw chat with a user, sent reply, immediately was logged out (I imagine this might be tough to reproduce, will report back here if it happens again.).  Also, I did just sign in on mWeb, not sure if it's possible that was some sort of trigger

app-36307f2….bundle.js:78
Skipping request and re-queueing:  Object
DevTools failed to load SourceMap: Could not load content for app://-/app-36307f2….bundle.js.map:
DevTools failed to load SourceMap: Could not load content for app://-/pdf.worker.entry-b22bab8….bundle.worker.js.map:
app-36307f2….bundle.js:78
Skipping request and re-queueing:  {command: "Report_AddComment", doNotRetry: false, isQueuePaused: true}
app-36307f2….bundle.js:78

Also, the message I sent right before it signed me out didn't get sent

Action Performed:
We don't have solid repro steps for this one.

Use the desktop app
Login in web with the same account as the desktop app.

Workaround:
Unknown
Platform:
Where is this issue occurring?
Web
iOS
Android
Desktop App ✔
Mobile Web
Version Number: 1.0.52-0
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
Expensify/Expensify Issue URL:
View all open jobs on Upwork

From @mallenexpensify https://expensify.slack.com/archives/C01GTK53T8Q/p1621964681193200

e.cash desktop app randomly signed me out. Logs and details in 🧵

Triggered auto assignment to @bfitzexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

Triggered auto assignment to @bondydaa (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

doesn't look like this qualifies for demolition team as is, maybe with more investigation someone can come up with easily produce-able steps but I don't think that person is me since I'm very unfamiliar with dot cash. Sending to the pool.

dropping this to monthly as well since it seems there's only one instance of this so far, if more cases start showing up then we can bump up the priority.

This just happened to me. I believe @parasharrajat has a theory on why.

Leaving closed cuz https://github.com/Expensify/App/issues/4657 looks like the same bug and it doesn't appear to be happening anymore


Parses sheet's CSS and remaps it accordingly for Discord on a per-sheet basis

Character Sheet Info Roll20 Internal Use only.


Galil Floating Bipod

A bipod floats somewhere on the map when the weapon itself is equipped. Bug occurred with the Tzalafim Handguard equipped.

Lol

This looks like some sort of attachment point issue.  Thanks for your report!

Fixed.


✨ implement INTERVAL as a custom type

There's a lot of bespoke code dotted around other functions handling INTERVALs, move this to a 'custom_type' folder, this should create a pattern to add in other custom types in the future.

https://www.postgresql.org/docs/current/functions-datetime.html


Unable to connect public Github repo

Describe the bug
"Connect GitHub repo" does not work for me.
To Reproduce
Steps to reproduce the behavior:

I copy and paste repo url and branch name
Click on Connect
Click on Train
See error "Error processing repo ... Make sure that main or master branch accessible ..."

https://github.com/FarManagerLegacy/macro-api
master

Hi @johnd0e, I was no able to reproduce there error, could you please try again and let us know if you still see it?
In any case, your repository does not seem to contain any Markdown or other supported files. We currently support .md, .mdoc, .mdx, .rst, .html, .htm and .txt.

Actually I've also tried a branch that contain .html files - gh-pages - without any luck either.
I would prefer to see more meaningful error message in case of no supported files found.
It could be convenient if you let more file extensions to be processed.

P.S.
My .text files are in fact markdown, but there is a reason not to have .md extension: there are a lot of flavors of markdown, and I use those .text as source for converting to different types, including github-flavored .md, as well as plain .txt.

I agree we should provide a more useful error message.
I was not able to reproduce your issue with the gh-pages branch, it seems to be processing the html file correctly on my end. So I wonder: do you have a custom include/exclusion path configuration by any chance?
I just pushed support for .text file extensions, which are treated as plain text files, so hopefully you should be able to get it working on the master branch.

So I wonder: do you have a custom include/exclusion path configuration by any chance?

Right now I have tried to do this with new just created project, without any configuration.
And it still fails.

Thanks a lot. I think I found the culprit, and pushed a fix: https://github.com/motifland/markprompt/issues/184


Create docs for entity schemas... Schemas schema?

Summary
Okay, i mean, i can't see any docs or schema formats for retrieved schema from /schemas path. It looks like json schema, or like openapi/swagger specs, but it isn't. So, i think, it is so neccessary to documentate it.
Also, i working on openapi schema for admin api, but i can't see a way, am i able to create pull request for it, or make my own repo?
Thanks a lot to contributors who makes kong, i really love you 🖤🖤🖤

@bungle

Hi @ololosha228, please have a look at https://docs.konghq.com/2.0.x/plugin-development/custom-entities/#defining-a-schema. If you have any specific questions, please feel free to post them here!

Need to reopen it. Problem is that docs doesn't properly explain differences betwen "record", "array" and "set", for example. Also i found in some plugins "uuid" type, which is actually "string" in json, but it's some way different for program, lol. Btw, reference property doesn't explain, where i need to found "somepluginentity" ref. but it is exist on some official plugins, for example.
My possible solution: user, who setting up kong instance can ignore internal-specific types like "record" or "uuid". so, i think, more important is to add jsonschema, or something rfc-standartized to /schemas response (even if kong supports url-encoded form, structure of query is absolutely same)


SOLR-16160 UpdateXmlMessages duplicate data when data is removed and …

SOLR-16160 UpdateXmlMessages duplicate data when data is removed and then added in the same message
https://issues.apache.org/jira/browse/SOLR-16160

Description
Investigated SOLR-16160 out of curiosity and was able to reproduce and add a unit test.
Looks like attempting an 'add-distinct' on an empty collection will accidentally add it twice, probably due to field sharing via 'existingField.getValues()' collection and calling 'doAdd' to add it again.
Solution
I think doSet is a more correct alternative because we already know there is one single value in the collection.
Tests
For unit test I followed the example provided in the ticket, tailored to match the existing tests.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[x] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

@risdenk thanks for taking a look. updated the CHANGES file too

Thanks @stillalex

thanks a lot @risdenk!


Cherry-pick (#214) into release-2.0

Summary
The release-2.0 branch has been created from the v2.0.0 tag. This PR cherry-picks #214 into that branch, so we can release a new v2.1.0 with only this change.
Ticket Link
--

@agarciamontoro I'm struggling to build this PR branch.
with node 13 I get an error.

With node 16 npm fetch never seems to end.
Can you provide a build or some troubleshooting ideas? :)
Maybe the node and npm version you are using to build this or a way to make circle CI build it.

@DHaussermann, build is also failing on CI. Let me check :pray:

Closing per https://community-daily.mattermost.com/core/pl/cix75ceit3neff7fgacyoo7uth, with the follow up being to release a new version off of master


[bug 1129703] Switch gengo balance check to use mailing list

This cleans up some code I wrote a while ago such that it now uses a
mailing list rather than mailing the admin when there are gengo
balance alerts.

This is pretty benign and the tests cover the sending situations pretty well. I'm going to self-r+ this (last one--I promise!).