otbr: ignore temporary settings files in migration script

[sairon]

In some cases, OTBR creates temporary settings files [1]. If the RCP becomes unavailable (seems to happen particularly for network connected adapters), file with a newer timestamp containing ephemeral data is created and incorrectly migrated as configuration for the reconnected adapter later:

Settings file for adapter 187a3efffe0182dd already exists at /data/thread/0_187a3efffe0182dd.data but appears to be old, archiving
Wrote new settings file to /data/thread/0_187a3efffe0182dd.data

This is how the thread folder looks like after the migration:

-rw------- 1 kpt kpt  32 Feb 11 09:57 0_0-tmp.data
-rw------- 1 kpt kpt  73 Feb 11 09:58 0_187a3efffe0182dd.data
-rw------- 1 kpt kpt 278 Feb 11 09:47 0_187a3efffe0182dd.data.backup-20260211095840

The new data file is clearly migrated from the 0_0-tmp.data, creating a new configuration out of ephemeral data which is invalid and prevents correct initialization of the OTBR app.

This change adds a check that the file to be migrated is matching a valid name created by [2], effectively ignoring the temporary files.

[1] https://github.com/openthread/openthread/blob/thread-reference-20250612/src/posix/platform/tmp_storage.cpp
[2] https://github.com/openthread/openthread/blob/thread-reference-20250612/src/posix/platform/settings.cpp#L93

Summary by CodeRabbit

• Bug Fixes
  • Migration now properly ignores ephemeral temporary settings files, improving reliability and preventing potential issues during the settings migration process.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR updates the OTBR addon from version 2.16.2 to 2.16.3. The migration script now validates OTBR settings file names against a regex pattern and skips files that don't match, ignoring ephemeral temporary files during migration.

Changes

Cohort / File(s)	Summary
Version Bump & Documentation openthread_border_router/CHANGELOG.md, openthread_border_router/config.yaml	Added changelog entry and bumped addon manifest version to 2.16.3, documenting the filtering of ephemeral temporary settings files during migration.
Migration Script Enhancement openthread_border_router/rootfs/usr/local/bin/migrate_otbr_settings.py	Added re module import and SETTINGS_FILE_PATTERN regex constant to validate OTBR settings file names. Applied pattern-based filtering to skip invalid files in both the main and secondary settings processing loops.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: ignoring temporary settings files in the OTBR migration script, which aligns with all three modified files (changelog, version bump, and migration script update).

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch otbr-dont-migrate-tmp

---

No actionable comments were generated in the recent review. 🎉

Tip

Issue Planner is now in beta. Read the docs and try it out! 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

• X
• Mastodon
• Reddit
• LinkedIn

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

[puddly]

Thanks! This new tmp file is likely the reason for the dataset corruption we were seeing occasionally.

[puddly]

Let's go with this approach. The 0_0-tmp.data file is unexpected and we should be ignoring it. If we run into further issues, we can validate further with #4413.

It's a terrible coincidence that both files are TLV format and share type IDs.