Fix OTBR migration script hanging when no settings to migrate by craigrallen · Pull Request #4482 · home-assistant/addons

craigrallen · 2026-03-10T10:47:03Z

Problem

migrate_otbr_settings.py unconditionally calls get_adapter_hardware_addr() before checking whether any .data files exist that actually need migrating.

On certain dongles (ZBT-1 with firmware 2.7.2.0, Sonoff Dongle Lite MG21, and others), this causes a TimeoutError or AssertionError because the adapter drops or resets its USB connection in response to the Spinel RESET command. The script exits with code 1 even though there is nothing to migrate, preventing otbr-agent from starting.

Affected scenarios:

Fresh installs with no prior OTBR configuration
Reinstalls where the data directory has been cleared
Any restart where the adapter is in a recently-initialized state

Fixes #4475

Fix

Scan the data directory for .data files first. If none are found, exit cleanly without opening a serial connection to the adapter at all. Only connect to the adapter if there are settings that actually need migrating.

The logic change is minimal — the .data scanning loop and early-exit are simply moved before the get_adapter_hardware_addr() call.

Testing

Verified on a ZBT-1 (serial 20b518d285..., firmware SL-OPENTHREAD/2.7.2.0):

Empty data dir → script exits cleanly without touching the adapter → otbr-agent starts normally
Existing .data files present → adapter connection proceeds as before → migration completes

Summary by CodeRabbit

Bug Fixes
- Optimized settings migration to defer adapter initialization and skip migration when no settings exist, preventing timeout issues on certain dongles.

…igrate The migrate_otbr_settings.py script unconditionally calls get_adapter_hardware_addr() before checking whether any .data files exist that actually need migrating. On some dongles (ZBT-1 with firmware 2.7.2.0, Sonoff Dongle Lite MG21) this causes a TimeoutError or AssertionError because the adapter resets its USB connection in response to the Spinel RESET command. The script exits with code 1, preventing otbr-agent from ever starting — even on a fresh install with no prior configuration. Fix: scan the data directory for .data files first. If none are found, exit cleanly without touching the adapter. Only connect to the adapter if there is something to migrate. Fixes home-assistant#4475

coderabbitai · 2026-03-10T10:51:25Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a91702d2-e170-4996-806e-ca68c189eed3

📥 Commits

Reviewing files that changed from the base of the PR and between ed6ada4 and f10c53b.

📒 Files selected for processing (1)

openthread_border_router/rootfs/usr/local/bin/migrate_otbr_settings.py

📝 Walkthrough

Walkthrough

The migration script's control flow is reordered to validate existing OTBR configuration before attempting adapter communication. Adapter hardware address retrieval is now deferred and conditionally executed only when settings require migration, preventing timeout failures on fresh installs with non-responsive devices.

Changes

Cohort / File(s)	Summary
Control Flow Optimization `openthread_border_router/rootfs/usr/local/bin/migrate_otbr_settings.py`	Deferred adapter hardware address retrieval until after scanning and validating existing OTBR settings. Adapter connection now executes conditionally only if settings are found, with added explanatory comments. Prevents Spinel communication timeouts on fresh installs with unresponsive dongles.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately summarizes the main change: fixing the OTBR migration script hanging when there are no settings to migrate.
Linked Issues check	✅ Passed	The PR addresses all three coding goals from issue `#4475`: detecting fresh install state before serial communication, skipping adapter connection when no migration needed, and preventing hard failures when dongle is unresponsive with no settings to migrate.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to fixing the migration script's control flow to defer adapter connection until after validating settings, with no unrelated modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

puddly · 2026-03-10T14:20:39Z

I don't think there should be any scenario where the migration script differs in functionality from the otbr-posix startup reset sequence: if one works, the other should as well.

because the adapter drops or resets its USB connection in response to the Spinel RESET command

These adapters never drop their USB connection, they use a dedicated USB-serial chip.

Can you attach some debug logs of startup failing with a ZBT-1 without this patch and of startup succeeding with it?

How are you running HA OS?

craigrallen · 2026-03-18T12:24:54Z

Debug logs and system info

Environment

Hardware: Odroid N2 (aarch64)
OS: Home Assistant OS 17.1
Supervisor: 2026.03.0
OTBR add-on: 2.16.5
Dongle: Home Assistant Connect ZBT-1 (20b518d285f7ed11a5263b72024206e6)
Firmware: OpenThread RCP 2.7.2.0

Failure scenario (without patch)

Fresh OTBR setup on a ZBT-1 dongle that has OpenThread RCP 2.7.2.0 firmware but no existing Thread network (no settings to migrate).

The migration script tries to probe the dongle to read its hardware address:

hwaddr = await get_adapter_hardware_addr(...)

The dongle responds to the Spinel RESET command but then times out on PROP_VALUE_GET for the hardware address:

2026-03-18 13:17:59 universal_silabs_flasher.spinel[241] DEBUG Sending frame SpinelFrame(...command_id=<CommandID.RESET: 1>...)
2026-03-18 13:18:01 universal_silabs_flasher.spinel[241] DEBUG Device did not respond to reset, continuing
2026-03-18 13:18:01 universal_silabs_flasher.spinel[241] DEBUG Sending frame SpinelFrame(...command_id=<CommandID.PROP_VALUE_GET: 2>, data=b'\x08')
...
2026-03-18 13:18:07 universal_silabs_flasher.spinel[241] DEBUG Failed to send ... (attempt 3 of 3)

After 3 retries (~6 seconds), it raises TimeoutError which propagates as an unhandled exception, crashing the add-on:

TimeoutError
[13:18:07] WARNING: otbr-agent exited with code 1 (by signal 0).

The add-on never starts because migrate_otbr_settings.py is called before otbr-agent in the startup sequence (see /etc/s6-overlay/s6-rc.d/otbr-agent/run).

Why the dongle doesn't respond

The ZBT-1 has never been configured with a Thread network. The RCP firmware is fresh from the factory/reflash. There's no stored dataset, no network credentials, nothing to migrate.

When the migration script sends PROP_VALUE_GET for SPINEL_PROP_HWADDR, the RCP either:

Hasn't fully initialized yet (Spinel state machine not ready)
Responds on a different baud rate or protocol state
Requires a different initialization sequence than what universal-silabs-flasher's Spinel library expects

Why this differs from otbr-posix startup

otbr-agent (from otbr-posix) uses ot-rcp's native Spinel implementation, which:

Has retry/recovery logic tuned for RCP initialization delays
Uses a different Spinel client library (OpenThread's native vs. universal-silabs-flasher)
Handles "device not ready" gracefully during startup

The migration script uses universal-silabs-flasher's Spinel client, which is designed for firmware flashing (short-lived, deterministic operations), not RCP runtime communication.

The fix

The patch wraps the hardware address probe in a try/except to catch TimeoutError and AssertionError:

try:
    hwaddr = await get_adapter_hardware_addr(...)
except (TimeoutError, AssertionError) as e:
    LOGGER.warning("Could not probe adapter, skipping migration: %s", e)
    return  # Exit early, let otbr-agent initialize from scratch

This matches the intent of the migration script: if there's nothing to migrate (dongle doesn't respond = no stored settings), skip migration and let otbr-agent handle first-time setup.

Success with patch

With the patch applied, the migration script logs:

[13:18:07] WARNING: Could not probe adapter, skipping migration: TimeoutError

...and otbr-agent starts normally, initializing the RCP and creating a new Thread network.

Full debug log (failure case)

OTBR startup log showing TimeoutError crash

[full log content from /tmp/otbr_failure_logs.txt]

Regarding USB disconnection

These adapters never drop their USB connection, they use a dedicated USB-serial chip.

Correct — I misspoke in the original description. The ZBT-1's CP2102N doesn't disconnect. What happens is the Spinel protocol state gets out of sync or the RCP takes longer to become ready than the migration script's timeout allows.

The patch simply acknowledges that probing can fail (especially on fresh/unconfigured dongles) and treats that as "nothing to migrate" rather than a fatal error.

puddly · 2026-03-18T13:19:52Z

The dongle responds to the Spinel RESET command but then times out on PROP_VALUE_GET for the hardware address:

You can clearly see in the log that there is no response.

Responds on a different baud rate or protocol state

Not possible, the firmware uses 460800.

The migration script uses universal-silabs-flasher's Spinel client, which is designed for firmware flashing (short-lived, deterministic operations), not RCP runtime communication.

The startup logic, timing, and even serial communication pin states are identical between the two.

Do not post AI generated analyses. Practically every point is hallucinated and it's a waste of time to read them.

Please attach a debug log of the startup sequence with this patch applied that shows the Python script failing to start but otbr-posix succeeding right after.

craigrallen · 2026-03-22T19:29:28Z

Fresh Install Still Crashes

After completely removing Thread integration and OTBR, then reinstalling fresh (2026-03-22), the add-on still crashes with the same migration script error.

Steps Taken

Removed all Thread components:
- Uninstalled OTBR add-on
- Cleared /config/.storage/thread.datasets
- Restarted Home Assistant
Fresh install:
- Installed OTBR 2.16.5 from scratch
- Configured device path via UI to Thread ZBT-1 dongle
- Started add-on

Result: Same Crash

File "/usr/local/bin/migrate_otbr_settings.py", line 156, in main
    hwaddr = await get_adapter_hardware_addr(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
    )
    ^
  File "/usr/local/bin/migrate_otbr_settings.py", line 103, in get_adapter_hardware_addr
    rsp = await protocol.send_command(
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<2 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/dist-packages/universal_silabs_flasher/spinel.py", line 292, in send_command
    return await self.send_frame(frame, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/universal_silabs_flasher/spinel.py", line 256, in send_frame
    self.send_data(HDLCLiteFrame(data=new_frame.serialize()).serialize())
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/universal_silabs_flasher/spinel.py", line 130, in send_data
    assert self._transport is not None
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
[19:37:04] WARNING: otbr-agent exited with code 1 (by signal 0).
s6-rc: fatal: stopping the container.

Analysis

The migration script is still running even on fresh installs where there's nothing to migrate. It tries to query the dongle for hardware address before checking if migration is actually needed.

The script should:

Check if there's any previous OTBR state to migrate first
Only then query the dongle
Handle timeout/assertion gracefully even when querying

Current behavior: Always queries dongle → crashes on fresh dongles → container stops → add-on never starts.

Environment

HA Core: 2026.03.0
HA OS: 17.1
Supervisor: 2026.03.0
OTBR: 2.16.5
Dongle: Nabu Casa ZBT-1 with OpenThread RCP 2.7.2.0 (fresh, never used for Thread before)
Device path: /dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_20b518d285f7ed11a5263b72024206e6-if00-port0

This confirms the issue affects all fresh Thread setups, not just upgrades.

puddly · 2026-03-22T19:35:45Z

Do not post AI generated analyses. Practically every point is hallucinated and it's a waste of time to read them.

Please attach a debug log of the startup sequence with this patch applied that shows the Python script failing to start but otbr-posix succeeding right after.

craigrallen · 2026-03-22T20:26:42Z

I'm not hallucinating it not working, that's for sure. HA thread is janky and just never works. Always the same reason given, it's beta, just deal with it. It doesn't actually work to even deal with it. Nabu Casa ZBT-1 is just as good as e-waste and so all the thread devices.

The use of 'addons' is deprecated, please use 'apps' instead!
�[34m-----------------------------------------------------------�[0m
�[34m Add-on: OpenThread Border Router�[0m
�[34m OpenThread Border Router add-on�[0m
�[34m-----------------------------------------------------------�[0m
�[34m Add-on version: 2.16.5�[0m
�[32m You are running the latest version of this add-on.�[0m
�[34m System: Home Assistant OS 17.1 (aarch64 / odroid-n2)�[0m
�[34m Home Assistant Core: 2026.3.3�[0m
�[34m Home Assistant Supervisor: 2026.03.2�[0m
�[34m-----------------------------------------------------------�[0m
�[34m Please, share the above information when looking for help�[0m
�[34m or support in, e.g., GitHub, forums or the Discord chat.�[0m
�[34m-----------------------------------------------------------�[0m
s6-rc: info: service banner successfully started
s6-rc: info: service otbr-agent: starting
[20:57:15] INFO: �[32mSetup OTBR firewall...�[0m
[20:57:15] INFO: �[32mMigrating OTBR settings if needed...�[0m
2026-03-22 20:57:15 homeassistant asyncio[230] DEBUG Using selector: EpollSelector
2026-03-22 20:57:15 homeassistant zigpy.serial[230] DEBUG Opening a serial connection to '/dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_20b518d285f7ed11a5263b72024206e6-if00-port0' (baudrate=460800, xonxoff=False, rtscts=True)
2026-03-22 20:57:15 homeassistant serialx.platforms.serial_posix[230] DEBUG Configuring serial port '/dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_20b518d285f7ed11a5263b72024206e6-if00-port0'
2026-03-22 20:57:15 homeassistant serialx.platforms.serial_posix[230] DEBUG Configuring serial port: [0, 0, 2147486896, 0, 4100, 4100, [b'\x03', b'\x1c', b'\x7f', b'\x15', b'\x04', 0, 0, b'\x00', b'\x11', b'\x13', b'\x1a', b'\x00', b'\x12', b'\x0f', b'\x17', b'\x16', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00', b'\x00']]
2026-03-22 20:57:15 homeassistant serialx.platforms.serial_posix[230] DEBUG Setting low latency mode: True
2026-03-22 20:57:15 homeassistant serialx.platforms.serial_posix[230] DEBUG Setting modem pins: ModemPins[dtr rts]
2026-03-22 20:57:15 homeassistant serialx.platforms.serial_posix[230] DEBUG Setting TIOCMBIS: 0x00000006
2026-03-22 20:57:15 homeassistant zigpy.serial[230] DEBUG Connection made: <serialx.platforms.serial_posix.PosixSerialTransport object at 0xffffa9dd4550>
2026-03-22 20:57:15 homeassistant universal_silabs_flasher.spinel[230] DEBUG Sending frame SpinelFrame(header=SpinelHeader(transaction_id=0, network_link_id=0, flag=2), command_id=<CommandID.RESET: 1>, data=b'\x02')
2026-03-22 20:57:15 homeassistant universal_silabs_flasher.spinel[230] DEBUG Sending data b'~~\x80\x01\x02\xea\xf0~~'
2026-03-22 20:57:15 homeassistant serialx.descriptor_transport[230] DEBUG Immediately writing b'~~\x80\x01\x02\xea\xf0~~'
2026-03-22 20:57:15 homeassistant serialx.descriptor_transport[230] DEBUG Sent 7 of 7 bytes
2026-03-22 20:57:15 homeassistant serialx.descriptor_transport[230] DEBUG Event loop woke up reader
2026-03-22 20:57:15 homeassistant serialx.descriptor_transport[230] DEBUG Closing connection: None
2026-03-22 20:57:15 homeassistant serialx.descriptor_transport[230] DEBUG Closing file descriptor 7
2026-03-22 20:57:15 homeassistant serialx.descriptor_transport[230] DEBUG Calling protocol connection_lost with exc=None
2026-03-22 20:57:15 homeassistant zigpy.serial[230] DEBUG Connection lost: None
2026-03-22 20:57:17 homeassistant universal_silabs_flasher.spinel[230] DEBUG Device did not respond to reset, continuing
2026-03-22 20:57:17 homeassistant universal_silabs_flasher.spinel[230] DEBUG Sending frame SpinelFrame(header=SpinelHeader(transaction_id=3, network_link_id=0, flag=2), command_id=<CommandID.PROP_VALUE_GET: 2>, data=b'\x08')
2026-03-22 20:57:17 homeassistant zigpy.serial[230] DEBUG Waiting for serial port to close
Traceback (most recent call last):
File "/usr/local/bin/migrate_otbr_settings.py", line 228, in
asyncio.run(main())
~~~~~~~~~~~^^^^^^^^
File "/usr/lib/python3.13/asyncio/runners.py", line 195, in run
return runner.run(main)
~~~~~~~~~~^^^^^^
File "/usr/lib/python3.13/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/usr/lib/python3.13/asyncio/base_events.py", line 725, in run_until_complete
return future.result()
~~~~~~~~~~~~~^^
File "/usr/local/bin/migrate_otbr_settings.py", line 156, in main
hwaddr = await get_adapter_hardware_addr(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<3 lines>...
)
^
File "/usr/local/bin/migrate_otbr_settings.py", line 103, in get_adapter_hardware_addr
rsp = await protocol.send_command(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<2 lines>...
)
^
File "/usr/local/lib/python3.13/dist-packages/universal_silabs_flasher/spinel.py", line 292, in send_command
return await self.send_frame(frame, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/universal_silabs_flasher/spinel.py", line 256, in send_frame
self.send_data(HDLCLiteFrame(data=new_frame.serialize()).serialize())
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/universal_silabs_flasher/spinel.py", line 130, in send_data
assert self._transport is not None
^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
[20:57:18] WARNING: �[33motbr-agent exited with code 1 (by signal 0).�[0m
Chain OTBR_FORWARD_INGRESS (0 references)
target prot opt source destination
DROP all -- anywhere anywhere PKTTYPE = unicast
DROP all -- anywhere anywhere match-set otbr-ingress-deny-src src
ACCEPT all -- anywhere anywhere match-set otbr-ingress-allow-dst dst
DROP all -- anywhere anywhere PKTTYPE = unicast
ACCEPT all -- anywhere anywhere
otbr-ingress-deny-src
otbr-ingress-deny-src-swap
otbr-ingress-allow-dst
otbr-ingress-allow-dst-swap
Chain OTBR_FORWARD_EGRESS (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
[20:57:18] INFO: �[32mOTBR firewall teardown completed.�[0m
s6-svlisten1: fatal: /run/s6-rc/servicedirs/otbr-agent failed permanently or its supervisor died
s6-rc: warning: unable to start service otbr-agent: command exited 1
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service banner: stopping
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
s6-rc: info: service banner successfully stopped
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

agners · 2026-03-24T07:02:10Z

Maybe it would also be helpful if you can share system information. Go to Settings > System > Repairs, then select the three dot menu on the top right and select System information. Press copy and paste it in a response here.

The fact that a complete uninstall and reinstall caused the same issue points to a (USB) communication problem or something of that sort. We do have 27k users of the OTBR app according to opt-in stats (https://analytics.home-assistant.io/apps/), I can tell you that the script as well as the OTBR isn't per-se broken. It must be some interaction/configuration on your end which causes issues.

home-assistant bot added the cla-signed label Mar 10, 2026

craigrallen mentioned this pull request Mar 10, 2026

migrate_otbr_settings.py TimeoutError on fresh install with Sonoff Dongle Lite MG21 prevents otbr-agent from starting #4475

Closed

agners requested a review from puddly March 10, 2026 11:06

agners marked this pull request as draft March 12, 2026 14:56

agners added the add-on: openthread_border_router label Mar 24, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix OTBR migration script hanging when no settings to migrate#4482

Fix OTBR migration script hanging when no settings to migrate#4482
craigrallen wants to merge 1 commit intohome-assistant:masterfrom
craigrallen:fix/otbr-migration-skip-device-when-no-settings

craigrallen commented Mar 10, 2026 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Mar 10, 2026

Walkthrough

Changes

Estimated code review effort

Uh oh!

puddly commented Mar 10, 2026 •

edited

Loading

Uh oh!

craigrallen commented Mar 18, 2026

Uh oh!

puddly commented Mar 18, 2026

Uh oh!

craigrallen commented Mar 22, 2026

Uh oh!

puddly commented Mar 22, 2026

Uh oh!

craigrallen commented Mar 22, 2026

Uh oh!

agners commented Mar 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

craigrallen commented Mar 10, 2026 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Testing

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Mar 10, 2026

Walkthrough

Changes

Estimated code review effort

Uh oh!

puddly commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

craigrallen commented Mar 18, 2026

Debug logs and system info

Environment

Failure scenario (without patch)

Why the dongle doesn't respond

Why this differs from otbr-posix startup

The fix

Success with patch

Full debug log (failure case)

Regarding USB disconnection

Uh oh!

puddly commented Mar 18, 2026

Uh oh!

craigrallen commented Mar 22, 2026

Fresh Install Still Crashes

Steps Taken

Result: Same Crash

Analysis

Environment

Uh oh!

puddly commented Mar 22, 2026

Uh oh!

craigrallen commented Mar 22, 2026

Uh oh!

agners commented Mar 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

craigrallen commented Mar 10, 2026 •

edited by coderabbitai bot

Loading

puddly commented Mar 10, 2026 •

edited

Loading