Bluetooth: Classic: add local name by chengkai15 · Pull Request #96621 · zephyrproject-rtos/zephyr

chengkai15 · 2025-09-26T12:19:57Z

add BR/EDR local name

jhedberg

We already have CONFIG_BT_DEVICE_NAME and bt_set_name() APIs. I don't think it makes sense to do BR/EDR-specific APIs for this.

chengkai15 · 2025-10-14T03:07:24Z

We already have CONFIG_BT_DEVICE_NAME and bt_set_name() APIs. I don't think it makes sense to do BR/EDR-specific APIs for this.

updated

lylezhu2012 · 2025-10-14T09:37:57Z

subsys/bluetooth/host/classic/br.c

+	err = bt_br_write_local_name(CONFIG_BT_DEVICE_NAME);
 	if (err) {
 		return err;
 	}

+	strncpy(bt_dev.name, CONFIG_BT_DEVICE_NAME, CONFIG_BT_DEVICE_NAME_MAX);
+


The device name storing feature will be broken by this change.

NO, It would not storing CONFIG_BT_DEVICE_NAME , which would be load when stack init.

otherwise local name would be to twice, when bt_enable, it would try to store user name, and check (bt_dev.name[0] == '\0') , then set local name again

int bt_enable(bt_ready_cb_t cb)
{
......
} else if (IS_ENABLED(CONFIG_BT_DEVICE_NAME_DYNAMIC)) {
err = bt_set_name(CONFIG_BT_DEVICE_NAME);
if (err) {
LOG_WRN("Failed to set device name (%d)", err);
}
}
......
}

static int commit_settings(void)
{
......
#if defined(CONFIG_BT_DEVICE_NAME_DYNAMIC)
if (bt_dev.name[0] == '\0') {
bt_set_name(CONFIG_BT_DEVICE_NAME);
}
#endif
......

I do not think so.

int bt_enable(bt_ready_cb_t cb) { ...... } else if (IS_ENABLED(CONFIG_BT_DEVICE_NAME_DYNAMIC)) { err = bt_set_name(CONFIG_BT_DEVICE_NAME); if (err) { LOG_WRN("Failed to set device name (%d)", err); } } ...... }

If the settings is not enabled and CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled, the name is stored into bt_dev.name. The default value is CONFIG_BT_DEVICE_NAME since the settings is not enabled.

static int commit_settings(void) { ...... #if defined(CONFIG_BT_DEVICE_NAME_DYNAMIC) if (bt_dev.name[0] == '\0') { bt_set_name(CONFIG_BT_DEVICE_NAME); } #endif ......

Or if the settings is enabled and CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled, the bt_dev.name is loaded from settings. If the name is not stored, the default value CONFIG_BT_DEVICE_NAME will be used and store it to settings.

If the settings is not enabled and CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled，that commit would meet the need. bt_dev.name would save last changed device name

and if the settings is enabled and CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled, if controller name has been changed, we need to cache name to bt_dev.name and store to settings

these cases would be handled well.

If the settings is not enabled and CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled，that commit would meet the need. bt_dev.name would save last changed device name

So, do you mean the change of the line 866 is used to fix the issue that the device name is incorrect when calling bt_get_name() if the settings is not enabled but CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled and function bt_set_name() is not called?

chengkai15 · 2025-10-23T03:03:10Z

Meant to request changes along with my previous comments

done

subsys/bluetooth/host/hci_core.c

lylezhu2012

I think there is a case missing in this PR.
The device name has been stored into NVM. And re-initialize the Bluetooth Host Stack.
The device name will not be written to the controller.

zephyr/subsys/bluetooth/host/settings.c

Lines 183 to 196 in ad7beb5

    
           #if defined(CONFIG_BT_DEVICE_NAME_DYNAMIC) 
        
           	if (!strncmp(name, "name", len)) { 
        
           		len = read_cb(cb_arg, &bt_dev.name, sizeof(bt_dev.name) - 1); 
        
           		if (len < 0) { 
        
           			LOG_ERR("Failed to read device name from storage" 
        
           			       " (err %zd)", len); 
        
           		} else { 
        
           			bt_dev.name[len] = '\0'; 
        
           			LOG_DBG("Name set to %s", bt_dev.name); 
        
           		} 
        
           		return 0; 
        
           	} 
        
           #endif

lylezhu2012 · 2025-10-24T01:57:56Z

subsys/bluetooth/host/hci_core.c

Why is the function name is changed here?

There are two cases if the classic feature is supported,

If the classic is not enabled, call function bt_br_init() of file subsys/bluetooth/host/hci_core.c‎ to read the buffer size.

Or, call function bt_br_init() of file subsys/bluetooth/host/classic/br.c

I only found the function name of bt_br_init() of file subsys/bluetooth/host/hci_core.c has been changed to br_hci_init(). The function bt_br_init() of file subsys/bluetooth/host/classic/br.c will not be called if Classic feature is enabled.

I think the changes will break the functionality of Bluetooth Classic.

@lylezhu2012 it would not affect classic functionality
there was discussion about that #96621 (comment)

Did you double confirm?

The function bt_br_init() of file subsys/bluetooth/host/classic/br.c is not called anymore in your PR.

And I tried your PR. No any device discovered by shell command br discovery on.

Please confirm you have tested your changes.

@lylezhu2012 name would only be get by RNR(remote name request), and EIR name feature would be add in later patch.

Did you double confirm?

The function bt_br_init() of file subsys/bluetooth/host/classic/br.c is not called anymore in your PR.

Yes, it only fix the warning that bt_br_init was conflict with another global variable br.h,

and I had to #include<classic/br.h> header because I was going to use IS_ENABLED CONFIG_BT_CLASSIC condition
from @jhedberg ‘s suggestion

**if (IS_ENABLED(CONFIG_BT_CLASSIC)) {** err = bt_br_write_local_name(bt_dev.name); if (err) { LOG_WRN("Unable to set local name"); return err; } }

name would only be get by RNR(remote name request), and EIR name feature would be add in later patch.

I do not think so. With the changes of PR, the initialisation of Bluetooth Classic will be bypassed (the function bt_br_init() will be not called anymore). It means in your PR, a function that was working properly was changed to not work anymore. I think it is a regression.

Yes, it only fix the warning that bt_br_init was conflict with another global variable br.h,

and I had to #include<classic/br.h> header because I was going to use IS_ENABLED CONFIG_BT_CLASSIC condition from @jhedberg ‘s suggestion

I understand why you change the function name. But I think he was just trying to give you some advice on the issue itself. I don't think he expects to solve the issue by introducing new issues.

I have some suggestions for you,

Put the implementation of function bt_br_write_local_name() to file hci_core.c,

Or, declare the prototype of the function bt_br_write_local_name() in file hci_core.h,

Or, create a new internal header file for Classic, just likes as br_internal.h or br_interface.h.

@lylezhu2012 NO，there is not change about bt_br_init but the name. I do not think old bt_br_init is a good design.
which only work when CONFIG_BT_CLASSIC was not define. Function names and implementations are opposite

if you has any question about that. please make it more clear.

I think it was more friendly to do something about classic bt hci init in the future. such as HCI flow control、Authenticaition timeout etc.

and I think the changes about bt_br_init is reasonable. The previous comment is my opinion

If there is a disagreement on the location of the bt_br_write_local_name function, we could discuss a best solution.

NO，there is not change about bt_br_init but the name. I do not think old bt_br_init is a good design. which only work when CONFIG_BT_CLASSIC was not define. Function names and implementations are opposite

Whether it is a good design or not, the regression cannot be accepted.

chengkai15 · 2025-10-24T09:41:51Z

I think there is a case missing in this PR. The device name has been stored into NVM. And re-initialize the Bluetooth Host Stack. The device name will not be written to the controller.

zephyr/subsys/bluetooth/host/settings.c

Lines 183 to 196 in ad7beb5

#if defined(CONFIG_BT_DEVICE_NAME_DYNAMIC)

if (!strncmp(name, "name", len)) {

len = read_cb(cb_arg, &bt_dev.name, sizeof(bt_dev.name) - 1);

if (len < 0) {

LOG_ERR("Failed to read device name from storage"

" (err %zd)", len);

} else {

bt_dev.name[len] = '\0';

LOG_DBG("Name set to %s", bt_dev.name);

}

return 0;

}

#endif

updated

sonarqubecloud · 2025-10-24T09:59:35Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

lylezhu2012 · 2025-10-24T10:14:55Z

subsys/bluetooth/host/settings.c

 	if (bt_dev.name[0] == '\0') {
 		bt_set_name(CONFIG_BT_DEVICE_NAME);
+	} else {
+		bt_set_name(bt_dev.name);


There is a potential issue that the life of Flash will be reduced. Since there is not any change of device name, I think it is better to write device name to controller directly.

that is to fix board reboot scenario.
I try to simulate the boot scenario here using settings_load to ensure commit_settings takes effect.

When I initiate the bt_set_name method, my log shows that commit_settings is not triggered.
Is this because my environment is not right?

do you means that if the name has been set before, and the same name would set again?
bt_set_name would check and will not take effect if it is set again

When I initiate the bt_set_name method, my log shows that commit_settings is not triggered. Is this because my environment is not right?

The commit_settings() would be called when the function settings_load() called.

do you means that if the name has been set before, and the same name would set again?

Uh-huh, that is what your change is doing.

bt_set_name would check and will not take effect if it is set again

In theory I think this can be done. But currently, the new name is not checked in function bt_set_name().

hi @lylezhu2012 @jhedberg please help review

I have verified last changes with qemu_x86 platform that the relevant functions and hci seem working normally, but this platform seems to be a pure memory simulation, and all data is lost after rebooting.

uart:~$ bt init Bluetooth initialized Settings Loaded [00:00:04.600,000] <dbg> bt_settings: bt_settings_init: [00:00:04.600,000] <inf> fs_nvs: 8 Sectors of 1024 bytes [00:00:04.600,000] <inf> fs_nvs: alloc wra: 0, 3e8 [00:00:04.600,000] <inf> fs_nvs: data wra: 0, 0 [00:00:04.600,000] <dbg> settings: settings_nvs_backend_init: Initialized [00:00:04.760,000] <inf> bt_hci_core: No ID address. App must call settings_load() [00:00:04.760,000] <dbg> bt_settings: commit_settings: [00:00:04.760,000] <inf> bt_hci_core: HCI transport: H:4 [00:00:04.760,000] <inf> bt_hci_core: Identity: 00:1B:DC:F4:B1:39 (public) [00:00:04.760,000] <inf> bt_hci_core: HCI: version 4.2 (0x08) revision 0x30e8, manufacturer 0x000a [00:00:04.760,000] <inf> bt_hci_core: LMP: version 4.2 (0x08) subver 0x30e8 [00:00:04.760,000] <dbg> bt_settings: commit_settings: Storing Identity Information uart:~$ bt settings-load Settings loaded [00:00:37.000,000] <dbg> bt_settings: set_setting: IRK[0] 5eaa77b537b4b4965d1cae18858595dc [00:00:37.000,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/irk [00:00:37.000,000] <dbg> bt_settings: set_setting: ID[0] 00:1B:DC:F4:B1:39 (public) [00:00:37.000,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/id [00:00:37.000,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/hash [00:00:37.000,000] <dbg> bt_settings: commit_settings: uart:~$ bt name "v1234" uart:~$ bt name Bluetooth Local Name: v1234 uart:~$ bt settings-load Settings loaded [00:01:20.980,000] <dbg> bt_settings: set_setting: Name set to v1234 [00:01:20.980,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/name [00:01:20.980,000] <dbg> bt_settings: set_setting: IRK[0] 5eaa77b537b4b4965d1cae18858595dc [00:01:20.980,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/irk [00:01:20.980,000] <dbg> bt_settings: set_setting: ID[0] 00:1B:DC:F4:B1:39 (public) [00:01:20.980,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/id [00:01:20.980,000] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/hash [00:01:20.980,000] <dbg> bt_settings: commit_settings: uart:~$ QEMU: Terminated

lylezhu2012 · 2025-10-24T10:37:14Z

subsys/bluetooth/host/hci_core.c

name would only be get by RNR(remote name request), and EIR name feature would be add in later patch.

I do not think so. With the changes of PR, the initialisation of Bluetooth Classic will be bypassed (the function bt_br_init() will be not called anymore). It means in your PR, a function that was working properly was changed to not work anymore. I think it is a regression.

Yes, it only fix the warning that bt_br_init was conflict with another global variable br.h,

and I had to #include<classic/br.h> header because I was going to use IS_ENABLED CONFIG_BT_CLASSIC condition from @jhedberg ‘s suggestion

I understand why you change the function name. But I think he was just trying to give you some advice on the issue itself. I don't think he expects to solve the issue by introducing new issues.

I have some suggestions for you,

Put the implementation of function bt_br_write_local_name() to file hci_core.c,

Or, declare the prototype of the function bt_br_write_local_name() in file hci_core.h,

Or, create a new internal header file for Classic, just likes as br_internal.h or br_interface.h.

jhedberg · 2025-11-27T11:59:02Z

@chengkai15 are you still working on this? There seems to be open review/discussion threads.

chengkai15 · 2025-12-25T02:17:16Z

@chengkai15 are you still working on this? There seems to be open review/discussion threads.

updated with last changes

github-actions · 2026-02-24T00:49:41Z

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

move bt local name commom hci to bt_br_write_local_name Signed-off-by: Kai Cheng <chengkai@xiaomi.com>

Implement dynamic local name update for BR/EDR connections. When CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled, the device name is now properly synchronized between LE and BR/EDR transports. Includes: - Update BR/EDR local name when bt_set_name() is called - Maintain consistency between LE and BR/EDR naming Signed-off-by: Kai Cheng <chengkai@xiaomi.com>

Add missing function declaration for bt_br_write_local_name() to resolve compilation errors when CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled. The function is now properly declared in classic.h header file to avoid implicit declaration warnings. Signed-off-by: Kai Cheng <chengkai@xiaomi.com>

When the controller supports BR/EDR and CONFIG_BT_CLASSIC is enabled, call bt_br_init() instead of br_hci_init() to perform the full BR/EDR Classic initialization (SSP mode, inquiry mode, local name, Class of Device, etc.). br_hci_init() is a local helper that only reads the buffer size for non-Classic configurations. Using it when CONFIG_BT_CLASSIC is enabled skips all Classic-specific HCI setup, breaking Bluetooth Classic functionality. Signed-off-by: Kai Cheng <chengkai@xiaomi.com>

sonarqubecloud · 2026-02-26T14:24:18Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

jhedberg · 2026-02-26T14:40:24Z

subsys/bluetooth/host/classic/br.c

-	strncpy((char *)name_cp->local_name, CONFIG_BT_DEVICE_NAME, sizeof(name_cp->local_name));
-
-	err = bt_hci_cmd_send_sync(BT_HCI_OP_WRITE_LOCAL_NAME, buf, NULL);
+	err = bt_br_write_local_name(CONFIG_BT_DEVICE_NAME);


The CONFIG_BT_DEVICE_NAME_DYNAMIC=y case should be handled in the settings commit callback, so you're missing a condition here:

/* The dynamic case is handled in commit_settings() */ if (!IS_ENABLED(CONFIG_BT_DEVICE_NAME_DYNAMIC)) { bt_br_write_local_name(CONFIG_BT_DEVICE_NAME); }

jhedberg · 2026-02-26T14:48:27Z

subsys/bluetooth/host/hci_core.c


-#if !defined(CONFIG_BT_CLASSIC)
-static int bt_br_init(void)
+static int br_hci_init(void)


Could you just rename this to hci_read_buffer_size()? That should hopefully eliminate confusion of having seemigly multiple "BR" init routines (this function isn't really a BR init routine, rather is just used to get the buffer size for LE in case the controller has the BR/EDR feature and doesn't have dedicated LE buffers.

jhedberg · 2026-02-26T14:49:41Z

subsys/bluetooth/host/hci_core.c

-		err = bt_br_init();
+		if (IS_ENABLED(CONFIG_BT_CLASSIC)) {
+			err = bt_br_init();
+		} else {


I suppse } else if (IS_ENABLED(CONFIG_BT_CONN)) { would be appropriate for this branch, to make it clear that it's only used for a specific combination of build time conditions. You should be able to remove any #ifdef guards from the called function itself, since it'll get stripped away by the linker if not called in practice.

jhedberg · 2026-02-26T14:52:54Z

subsys/bluetooth/host/hci_core.c

 		}
 	}

+	if (IS_ENABLED(CONFIG_BT_CLASSIC)) {


Until now bt_set_name() hasn't required HCI initialization to have completed. Now that you're actually trying to send a HCI command from here you're introducing that requirement. I think you're missing a condition here:

if (IS_ENABLED(CONFIG_BT_CLASSIC) && atomic_test_bit(bt_dev.flags, BT_DEV_READY)) {

jhedberg · 2026-02-26T14:57:55Z

subsys/bluetooth/host/settings.c

+			CONFIG_BT_DEVICE_NAME_MAX);
+		bt_dev.name[CONFIG_BT_DEVICE_NAME_MAX] = '\0';
+	} else {
+		bt_set_name(bt_dev.name);


This doesn't look correct since the purpose of bt_set_name() is to copy the given value to bt_dev.name. Therefore, calling it by passing bt_dev.name as the argument is odd at best. I think the logic should go something like:

if (bt_dev.name[0] == '\0') { bt_set_name(CONFIG_BT_DEVICE_NAME); } if (IS_ENABLED(CONFIG_BT_CLASSIC) { bt_br_write_local_name(bt_dev.name); }

zephyrbot added area: Bluetooth Classic Bluetooth Classic (BR/EDR) area: Bluetooth area: Bluetooth Host Bluetooth Host (excluding BR/EDR) labels Sep 26, 2025

zephyrbot requested review from HaavardRei, MarkWangChinese, PavelVPV, Thalley, alwa-nordic, cvinayak, gzh-terry, hermabe, jhedberg, lylezhu2012, makeshi, rugeGerritsen and sjanc September 26, 2025 12:21

zephyrbot assigned lylezhu2012 Sep 26, 2025

Thalley removed their request for review September 26, 2025 12:31

jhedberg requested changes Sep 26, 2025

View reviewed changes

HaavardRei removed their request for review September 30, 2025 13:13

chengkai15 force-pushed the dev_name branch from 089cb6e to eacf9f4 Compare October 14, 2025 03:07

chengkai15 closed this Oct 14, 2025

chengkai15 reopened this Oct 14, 2025

chengkai15 requested a review from jhedberg October 14, 2025 03:07

chengkai15 force-pushed the dev_name branch from eacf9f4 to 723ffc0 Compare October 14, 2025 06:21

lylezhu2012 requested changes Oct 14, 2025

View reviewed changes

cvinayak removed their request for review October 15, 2025 06:42

chengkai15 requested a review from lylezhu2012 October 15, 2025 14:35

chengkai15 force-pushed the dev_name branch from 723ffc0 to 271538c Compare October 16, 2025 11:30

chengkai15 force-pushed the dev_name branch from d4b2b6b to de960b8 Compare October 23, 2025 03:49

chengkai15 commented Oct 23, 2025

View reviewed changes

subsys/bluetooth/host/hci_core.c Show resolved Hide resolved

chengkai15 force-pushed the dev_name branch from de960b8 to af11a65 Compare October 23, 2025 14:21

jhedberg previously approved these changes Oct 23, 2025

View reviewed changes

gzh-terry previously approved these changes Oct 24, 2025

View reviewed changes

lylezhu2012 requested changes Oct 24, 2025

View reviewed changes

chengkai15 requested a review from lylezhu2012 October 24, 2025 08:00

chengkai15 dismissed stale reviews from gzh-terry and jhedberg via 4a98066 October 24, 2025 09:41

chengkai15 force-pushed the dev_name branch from af11a65 to 4a98066 Compare October 24, 2025 09:41

chengkai15 requested review from gzh-terry and jhedberg October 24, 2025 09:42

lylezhu2012 requested changes Oct 24, 2025

View reviewed changes

jhedberg added this to the v4.4.0 milestone Oct 27, 2025

github-actions bot added the Stale label Feb 24, 2026

chengkai15 added 4 commits February 26, 2026 21:08

Blueototh: Classic: move bt local name common to bt_br_write_local_name

a9b13e4

move bt local name commom hci to bt_br_write_local_name Signed-off-by: Kai Cheng <chengkai@xiaomi.com>

chengkai15 force-pushed the dev_name branch from 4a98066 to e50f9c4 Compare February 26, 2026 14:17

chengkai15 requested a review from lylezhu2012 February 26, 2026 14:18

jhedberg removed the Stale label Feb 26, 2026

jhedberg requested changes Feb 26, 2026

View reviewed changes

	#if defined(CONFIG_BT_DEVICE_NAME_DYNAMIC)
	if (!strncmp(name, "name", len)) {
	len = read_cb(cb_arg, &bt_dev.name, sizeof(bt_dev.name) - 1);
	if (len < 0) {
	LOG_ERR("Failed to read device name from storage"
	" (err %zd)", len);
	} else {
	bt_dev.name[len] = '\0';

	LOG_DBG("Name set to %s", bt_dev.name);
	}
	return 0;
	}
	#endif

Conversation

chengkai15 commented Sep 26, 2025

jhedberg left a comment

Choose a reason for hiding this comment

chengkai15 commented Oct 14, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lylezhu2012 Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

chengkai15 Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

lylezhu2012 Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

chengkai15 commented Oct 23, 2025

Uh oh!

lylezhu2012 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chengkai15 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

lylezhu2012 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

lylezhu2012 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chengkai15 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

lylezhu2012 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

chengkai15 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chengkai15 commented Oct 24, 2025

sonarqubecloud bot commented Oct 24, 2025

Quality Gate passed

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chengkai15 Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

lylezhu2012 Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

jhedberg commented Nov 27, 2025

chengkai15 commented Dec 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

github-actions bot commented Feb 24, 2026

sonarqubecloud bot commented Feb 26, 2026

Quality Gate passed

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Labels

5 participants

lylezhu2012 Oct 16, 2025 •

edited

Loading

chengkai15 Oct 16, 2025 •

edited

Loading

lylezhu2012 Oct 17, 2025 •

edited

Loading

chengkai15 Oct 24, 2025 •

edited

Loading

lylezhu2012 Oct 24, 2025 •

edited

Loading

lylezhu2012 Oct 24, 2025 •

edited

Loading

chengkai15 Oct 24, 2025 •

edited

Loading

lylezhu2012 Oct 24, 2025 •

edited

Loading

chengkai15 Oct 24, 2025 •

edited

Loading

chengkai15 Feb 26, 2026 •

edited

Loading

lylezhu2012 Oct 24, 2025 •

edited

Loading

chengkai15 commented Dec 25, 2025 •

edited

Loading