Dev Feed

Version: 0.55.2 (tested latest) & 0.54.0 (version I usually run on) ``` npx dprint fmt --config dprint.json --config-discovery=ignore-descendants thread 'tokio-runtime-worker' (29448642) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/alloc/src/slice.rs:520:23:

Version: 0.55.2 (tested latest) & 0.54.0 (version I usually run on) ``` npx dprint fmt --config dprint.json --config-discovery=ignore-descendants thread 'tokio-runtime-worker' (29448642) panicked at /rustc/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/library/alloc/src/slice.rs:520:23: capacity overflow note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Repository is 200KB in size Happens in a smaller repository too (~60KB). Using in conjunction with `"@dprint/typescript": "0.96.1"` `dprint.json` ``` { "includes": [ "lib/**/*.ts", "tests/**/*.ts" ], "lineWidth": 120, "incremental": true, "typescript": { "quoteStyle": "alwaysSingle", "semiColons": "always", "indentWidth": 2, "useTabs": false, "memberExpression.linePerExpression": false, "arrowFunction.useParentheses": "maintain" }, "plugins": [ "${configDir}/node_modules/@dprint/typescript/plugin.wasm" ] } ``` Similar here: https://github.com/dprint/dprint/issues/252 https://github.com/dprint/dprint/issues/669

<!-- Please search existing issues to avoid creating duplicates. --> <!-- Please fill out ALL ITEMS in the bug report. We simply can't fix bugs if we don't have all the information --> - Sequel Ace Version (including build number): 5.3.0 (20102) - Sequel Ace Source (App Store/GitHub/Homebrew): Homebrew - macOS Version: 26.5.2 (25F84) - Processor Type (Intel/Apple): Apple

<!-- Please search existing issues to avoid creating duplicates. --> <!-- Please fill out ALL ITEMS in the bug report. We simply can't fix bugs if we don't have all the information --> - Sequel Ace Version (including build number): 5.3.0 (20102) - Sequel Ace Source (App Store/GitHub/Homebrew): Homebrew - macOS Version: 26.5.2 (25F84) - Processor Type (Intel/Apple): Apple - MySQL Version: 8.0.39 - macOS Localization: GB-UK **Is Issue Present in [Latest Beta](https://github.com/Sequel-Ace/Sequel-Ace/releases)?** <!-- Please try the [latest beta](https://github.com/Sequel-Ace/Sequel-Ace/releases). If the latest beta works, we've fixed the issue already and will get the fix out soon. There's no need to open a new issue for a bug already fixed in the latest beta. --> No mention of this bug fixed in the pre-release notes. **Description** When attempting to delete a column via the GUI I was presented with the macOS spinning circle of doom. The app became unresponsive, and then crashed. The column was still being dropped in the background when I looked at the showprocess list after re-loading Sequel Ace. The detail here is that this table had an expensive FULLTEXT index on a large text column, on a 5 million row data set. This index forces a COPY TABLE command in order to drop a column. This means dropping a column is a long-running process. **Steps To Reproduce** 1. Create a table that will mean dropping a column does not run instantly. 2. For my table, the runtime was about 40 minutes 3. Drop a column on a database 4. Notice that the macOS spinner of doom is presented after a small number of seconds (3/4) **Expected Behaviour** <!-- A clear and concise description of what you expected to happen. --> The app should not crash if the drop column command is taking a long time. The app should indicate that the drop is taking a long time, by way of some responsive mechanism. **Related Issues** <!-- Please search [Issues on GitHub](https://github.com/Sequel-Ace/Sequel-Ace/issues?q=is%3Aissue), including Closed Issues, for the bug. If the bug has been fixed and is pending release, there may already be a closed issue for it. If an existing report of your issue already exists, please don't open a new issue and refer to the existing issue. --> **Additional Context** <!-- Add any other context about the problem here. --> <!-- Please ATTACH any SCREENSHOTS AND CRASH LOGS that might help investigating and addressing the issue. --> <!-- Please please please attach crash logs (as zip files if needed) and don't paste the content of the crash itself, it's much easier for us to work with files than massive text blocks --> Not something you really want to do that often in a GUI given this kind of DDL change should be handed by migrations, but I was trying to get a feel of how long this took on a test database before writing a codified migration.