Crash loop after resizing a column on a database with a long file path

[flostellbrink]

What happened?

The app crashed while I used a SQLite database, and then crashed a few seconds after every start.

The trigger is a resized column. The column layout syncs to iCloud, and the record name embeds the connection UUID, the URL-encoded database path, and the table name. My database path makes that name 262 characters, over CloudKit's 255 limit. CKRecordID(recordName:) throws inside a Swift async task, and the app segfaults some seconds to a minute later with EXC_BAD_ACCESS in swift_task_isCurrentExecutorWithFlagsImpl, from varying call sites. The sync retries on every launch, which makes it a start-up crash loop. Deleting the file in Application Support/TablePro/ColumnLayout/ stops the loop until the next resize.

Steps to reproduce

1. Open a SQLite database with a long absolute path, for example a wrangler path: <project>/api/.wrangler/state/v3/d1/miniflare-D1DatabaseObject/<64-hex-chars>.sqlite. It reproduces when UUID + encoded path + table name pass 255 characters.
2. Have iCloud sync enabled.
3. Resize any column in any table.
4. Keep using the app, or restart it. It crashes within a minute, and again on every launch.

Expected behavior

Resizing a column on a database with a long path does not crash the app, and settings sync failures do not prevent start-up.

Database type

SQLite

TablePro version

0.68.0 (123), 0.69.0 (125)

macOS version & chip

macOS 26.6 (25G72) / Apple Silicon

Screenshots / Logs

Unified log at the throw:

TablePro: (AppKit) [com.apple.AppKit:General] recordName (Settings_columnLayout.B08776B3%2DD76C%2D4692%2DB8CB%2D79DA916525B7.%2FUsers%2F…%2Ewrangler%2Fstate%2Fv3%2Fd1%2Fminiflare%2DD1DatabaseObject%2Ffbe04…%2Esqlite..d1%5Fmigrations) is too long
3  CloudKit  $sSo10CKRecordIDC8CloudKitE10recordName04zoneB0ABSS_So0a4ZoneB0CtcfC + 88
...
11 libswift_Concurrency.dylib  completeTaskWithClosure
TablePro: (HIServices) [com.apple.hiservices:HIExceptions] FAULT: CKException

Crashed thread of the later segfault (same in all ~25 reports):

EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS
0 libswiftCore.dylib          swift_getObjectType
1 libswift_Concurrency.dylib  swift_task_isMainExecutorImpl
2 libswift_Concurrency.dylib  swift::SerialExecutorRef::isMainExecutor()
3 libswift_Concurrency.dylib  swift_task_isCurrentExecutorWithFlagsImpl
4 TablePro                    0x136900 (varies per crash)