Unify export workflow with a configurable wizard and explicit failure handling

[openai0229]

Chat2DB Edition

Chat2DB Community

User Problem

Export choices are split across separate entry points. The table-data dialog submits one table even though the task API supports multiple tables, and database export failure handling is determined by the implementation rather than an explicit user choice.

Reviewing #2739 exposed the need to define the complete workflow before merging a fixed skip-on-error policy. A user must be able to choose what to export, understand what happens on failure, and distinguish a complete export from a partial result.

Concrete Use Case

A user starts an export from a table or database/schema in the object tree. They select the current table, several tables, or the supported objects in that database/schema; choose structure, data, or both; choose an output format and destination; review the settings; and start one tracked export task.

If one object cannot be read, the task follows the user's chosen policy. The result identifies completed, failed, and skipped objects and allows retrying the failed objects.

Product Area

Import or export

Proposed Outcome

Create a unified export wizard, reusing the existing task system and applicable export implementations.

1. Objects and scope: preselect the object from the entry point and allow explicit selection of one table, multiple tables, or a database/schema. Show only scopes and object types supported by the selected datasource.
2. Content and format: offer structure, data, or both where supported. Only allow formats compatible with that content. Shared settings should behave consistently when entered from a table, database/schema, or query result; a query-result export keeps its existing result scope.
3. Output: choose the destination and filename, with a sensible extension and a preview of the output files. Offer a combined file or separate files in an archive where the format supports it. Handle existing destination files with a clear user decision; never silently overwrite them.
4. Failure handling: default to stopping on error. Offer an explicit option to skip a failed object and continue. Persist the chosen policy in the task specification and apply it consistently across the relevant generic and database-specific export paths.
5. Progress and results: report per-object progress and a final summary of completed, failed, and skipped objects. A partial export must be visibly identified. Allow retrying failed objects without silently exporting completed objects again.

Correctness requirements apply under either failure policy:

• An object counted as skipped contributes no partial SQL or data to the published output. In particular, an incomplete table must not leave DROP/CREATE statements and only some of its rows.
• Output files and archive entries must keep their respective contents when names collide after normalization, case folding, or suffix generation.
• Cancellation and output/staging I/O failures stop the task and clean up incomplete output; they must not be reclassified as an unreadable object that can be skipped.
• Preserve supported export formats, SQL quoting, and existing permission checks.

Ownership and design gate: maintainers will lead the interaction design and task-contract decisions. This is planning work, not a request for @HandSonic to expand #2739 into a new workflow. Define the capability/format matrix, failure semantics, result model, and compatibility with existing callers before splitting implementation into bounded tasks.

Completion criteria

• One consistent wizard covers the applicable existing export entry points and exposes multi-table selection.
• The confirmation step shows scope, content, format, output names, and failure policy.
• Cancelling the wizard creates no task or output.
• Stop-on-error and continue-on-error produce the documented task status and per-object results.
• Retrying failed objects preserves the selected settings and does not duplicate completed work.
• No failed-object fragments or filename collisions corrupt a published artifact.
• Web and desktop interactions use the same choices, with appropriate destination handling.
• Regression tests and Playwright validation cover successful exports, failures before and during object export, cancellation, filesystem collisions, and refresh/persistence.

Verification references

PR #2739 contains useful implementation and regression-test evidence; retain it as a reference rather than treating the closed PR as a completed feature. Its head at review is 54c411aa2679ade7af23102d1c4b8b23d7e6c08c.

The review reproduced a database read failure after 100,000 exported rows and a filename collision using db1/users, db2/users, and USERS-2 on a case-insensitive filesystem. These cases should remain regression coverage in the redesigned workflow.

Related request: #2236, choosing the export filename. Coordinate that requirement here without closing it as implemented.

Alternatives Considered

Merge #2739 as a local backend fix and keep the existing dialogs. This protects output integrity but leaves scope selection, failure policy, and partial-result feedback fragmented. We will define the unified workflow first and reuse the applicable fixes and tests with attribution.

This issue is scoped to export. It does not propose an import redesign, a replacement task framework, new database drivers, scheduling, or new export formats.

Contribution

I can submit a pull request.

Maintainer-led planning; external implementation tasks will be scoped after the design is agreed.

Submission Checklist

• I searched existing issues and Discussions for duplicates.
• I selected the affected Chat2DB edition.

[openai0229]

Related open reports collected while planning this export workflow:

Issue	Requirement or verification to carry forward
#2236	Choose the export filename, preserve the format extension, and make destination conflicts an explicit user decision.
#2501	Render export status without mutating store state; distinguish complete, failed, and partial results. Recheck the earlier UI report against the current task center.
#2503	Recover from failed progress/log requests and retrieve the real terminal status without restarting the export task.
#2509	Retain stream and temporary-file cleanup on failure/cancellation. The current implementation no longer uses the InputStream[] structure described in the original report; preserve this as a regression case.
#2545	Preserve applicable SQL-input restrictions and permissions for CSV/Excel query-result export. The report still needs reproduction evidence.
#2477	Account for Presto DDL capability and failure reporting when offering structure export. The plugin-specific defect remains separately tracked in that issue.

Each issue has received a reply directing the shared workflow discussion here. This issue coordinates the export design; the individual reports remain open until their own behavior has been verified and resolved. Import-only requests and unrelated database-management work remain outside this export scope.